On 30 Mei 2010, at 19:47, Jonas Maebe wrote: > They should not be using any FPC functionality relying on floating point. Any > person who uses floating point should know that by definition it is inexact > (ranging from "a little" to "enormously", depending on what you do).
I understand. > That last sentence is a fundamental principle of any algorithm that uses > floating point. I see. > If you need exact date/time calculations, you cannot use TDateTime. In fact, > several of the TDateTime helpers are literally defined as only offering > approximations (e.g. > http://www.freepascal.org/docs-html/rtl/dateutils/monthspan.html). I understand that to have exact and precise date/time calculation, I can't use TDateTime. I am not asking for complete rewrite of DateUtils. I was just showing a small common mistake that could lead to a serious error in date/time calculation for common programming need. The source of the problem is clear. Can't we just supply a simple workaround for that bug? Instead of discussion about the risk of using floating point calculation. Say for example, when msec part of a or b (in the previous code snippet) is equal to zero, the library will "autocorrect" it to prevent the bug arises. Or, the less precise functions e.g. HoursBetween, DaysBetween, etc could simply ignore the msec part. Common usage won't care about the msec anyway. The msec part would be truly taken into account on MilisecondsBetween function where the msec value does matter. Or, at least, if we don't want to fix it, then state the bug clearly in the docs with "won't fix" status or something. So the users would have been warned since the beginning (I assume they read the docs) and they can carefully use TDateTime especially when involving msec part. > You have to implement a separate unit that is written from the start to offer > the precision that you require if you need more than what TDateTime offers. I don't need to write a rocket launcher app, yet. :D But if I do, I surely take your advice. I just want to use DateUtils unit safely by ignoring msec values which could lead to a serious bug while I don't really care about its value. -Bee- _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
