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.

--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply via email to