In our previous episode, Bee Jay said: > > Then it shouldn't use floating point. Ever. > > Well... then it shouldn't be using FPC? ;)
This kind of problems are universal, and TDateTime is a library invention. If you have an integer date based library, you can use that instead. > Ok, forget about the rocket launcher. The important note that I think need > to be addressed is the bug only occurs if the milisecond part of a or b is > 0. Other than 0, then those functions work correctly. > > I believe most of us rarely write a program that need precision to > milisecond, usually we simply put 0 on the milisecond part. The worst > thing is, the other similar functions e.g. HoursBetween etc. which > commonly used are also affected by the bug. So, the simple thing could > lead to a serious problem. It is a limitation of *between definition and the used format. The information is not there, so nothing can be done. Therefore a bugreport would not make sense. These are simple "handy and cheap" helper functions for relative imprecise business logic, nothing more. For special purpose usage, one could make a separate unit. (e.g. base on a record type with two int64's). But start reading the calendar FAQ first. This is not the only problem with dates :-) _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
