[Lazarus] DateDif function needed

waldo kitty wkitty42 at windstream.net
Sun Nov 10 01:10:28 CET 2013

```On 11/9/2013 1:48 PM, Jürgen Hestermann wrote:
> Am 2013-11-09 18:31, schrieb Michael Van Canneyt:
>  > On Sat, 9 Nov 2013, Jürgen Hestermann wrote:
>  >> Storing dates as floats has a lot of drawbacks.
>  >> It's inaccurate, you always need a starting date and get other problems.
>  > Can you prove this statement ?
>
> Well, aren't the current mails about incorrect YearsBetween calculation proof
> enough?

i misunderstood the given functions... sorry :?

> If you need to use an approximate value for days in the year then some is wrong
> IMO.

i have been working on this most all day and there's no way around it with
simple functions... they must be more intricate than what i've seen or created
so far...

> For the same difference between two time floats it can be a full year or not
> depending on whether a leap year is included or not.

and there's the rub... if you want the difference between two dates and times,
how do you calculate if there is a leap year involved, which year of the date is
involved and how do you feed that to the *Between routines? you can't from what
i've seen... however the *Span routines i've been pointed to may very well
handle this...

what i've seen is like comarping this

2013/01/01 00:00:00.000
2014/01/01 00:00:00.001

and getting this
MilliSecondsBetween(A1,A2) = 31536000001

but this is an estimated value because

RealMSPerYear = 31557600000

is what you get with 365.25 days per year...

but then looking at those two values, you cannot tell if a leap year is involved
in there or not... much less if there are two or more leap years...

back in the day, routines that i used to do this in TP/BP converted the
date/time values to julian date values, worked on them for the difference and
then converted back to individual year, months, day, etc... but then things
break when traversing over period count changes or trying to go between
different calendar formats... it was ugly then and still ugly now... i just hope
that what i had then is available now via built-in library routines or is easily
built from the library routines ;)

--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.

```