[Lazarus] DateDif function needed

[Lukasz Sokol]

On 14/11/13 17:48, Jürgen Hestermann wrote:
> Am 2013-11-14 07:56, schrieb Patrick Chevalley:
[...]
> 
>> The julian year of 365.25 is a convenient approximation still in
>> use despite the julian calendar was abrogated some 400 years ago.
> 
> Of what use would it be to use 365.25 days as a representation of a
> year? You can also use 400 instead. It would be just an arbitrary
> definition decoupled from calendars. You cannot calculate anything
> useful with it. Neither calendar dates nor astronomical things. It is
> just an accademic value and exists only because it is "so easy to
> use".
> 

You know what they say about statistics: there are lies, big lies and there is statistics.

Statistics only works if you have large enough data set to calculate the model from... 
(and /similarly/ or same large data set to extrapolate from, thereafter)

(http://en.wikipedia.org/wiki/Gregorian_calendar is a fascinating read :] )

And for what it's worth, the fraction-based calculations should be then far less [time...] consuming,
to just add/subtract/multiply/divide the fractions, than counting the days/hours/mintues/secods one by one... 
(Only, it needs to be done right :> and the leap year/leap month/30-31day exceptions observed when it comes
to the dates: 1 day is at least 0.00273790700 of an average year as in 1/365.2425 - keep too little of
this fraction or even worse: corrupt it, and you're in for a bad result...) 

Problems may arise with improper rounding up or down, and floating point bugs 
(assuming the fraction part of TDateTime to be miliseconds / MilisecondsPerDay : Pentium FPU anybody?)

On the other hand if the calculations were Gregorian year based (365.2425...) it'll now be good enough
for calculating all western calendar dates since 15/10/1582  :) and to some extent, predict into next century or so.

-L :)