| Skatterbrainz |
| (Starting to like KiXtart) |
| 2008-03-22 04:19 AM |
|
DateDiff, DateAdd
|
I know there's plenty of UDF's for this, but everytime I turn around it seems there's a bug being fixed or someone suggesting an alternate method. Would it be possible to build in DateDiff and DateAdd functions to make it easier to compare and calculate date and time results? WSH makes it pretty simple. I really like Kix more, but having to add things like this seem unnecessary and obvious enough to have built-in. Maybe I'm the only one that feels this way, but this is the suggestion forum, so hopefully this doesn't cause anyone too much grief.
| Les |
| (KiX Master) |
| 2008-03-22 06:44 PM |
|
Re: DateDiff, DateAdd
|
Not sure what bugs and/or fixes there are/have been. The beauty of alternate methods is you get to choose what's best for your need.
I'm not familiar with what in WSH would simplify things. Date and time can take different formats so various methods are needed. IMHO there are enough UDFs around to address the various needs.
I think intrinsic code to handle all the diverse needs will bloat KiX for the many and benefit the few. My two cents anyway.
Glenn Barnas
|
| (KiX Supporter) |
| 2008-03-22 06:51 PM |
|
|
Re: DateDiff, DateAdd
|
The TimeDiff and TimeConvert (which use similar logic) provide a high degree of accuracy. From the header:
"Validated by generating sequential date values from 1/1/1883 to 12/31/2105, a range of just over 8.5 Billion seconds."
The 1883 date was chosed pretty much at random for the sequential testing. Random testing for dates between 1 and the year 3000 was also done.
The logic used by these UDFs is widely regarded as the standard method of date calculation.
TimeDiff returns the difference in time (in seconds) between two dates. Alternate values can be specified, such as minutes, hours, or days. For short duration calculations, it can calculate and return millisecond accuracy. I say "short durations" due to limits of double-precision. Generally, for anything over a few days, milliseconds won't matter anyway.
TimeConvert uses the same algorithm, but converts a date/time string to cTime format - the number of seconds that elapsed since an epoch date. It defaults to a standard computer epoch date of 1/1/1970, but any date can be used and it will return the seconds from midnight of that date.
Also, note that the calendar as we know it changed in Sept, 1752. 11 days were removed (Sept 3-13) to "catch up" for bad leap year calculations (among other discrepencies). None of the date calculations take this into account, so calculations that span those dates (unlikely) will probably need to make specific adjustments.
Code:
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Glenn
| cj |
| (MM club member) |
| 2008-05-01 09:40 AM |
|
|
Re: DateDiff, DateAdd
|
Just to add another method to the mix
The TDateTime class in Delphi (Pascal) uses a float for dates and times counting from midnight on the 30th of December 1899 as 0.0.The whole number is the number of days since that date and the fractional component is the time since midnight. so .25 is 0600 and .5 is noon etc.
As I type this, it's 01/05/2008 17:37:03 which is 39569.7340687384. This is a cool system as you get as much accuracy as the computer can count. Typically you would format it down to milliseconds at the most.
Getting the difference in dates is just one number minus the other with or without the fractions if you care for the times. I was born at 26961.3958395718, so I am now 12608.3382291666 days old.
In fact, here's a little app to show those numbers in action...
cj
|
Richard H.
|
| (KiX Supporter) |
| 2008-05-01 11:35 AM |
|
Re: DateDiff, DateAdd
|
Quote:
This is a cool system as you get as much accuracy as the computer can count
Using floats is actually not a great idea as it is not very portable and can lead to errors, the accuracy of the computer is somewhat less than you think
Specifically, floating point math / storage uses approximation which causes rounding errors. Google for "floating point approximation" if you want more information.
| Sealeopard |
| (KiX Master) |
| 2008-05-02 04:33 AM |
|
|
Re: DateDiff, DateAdd
|
Don't even get me started on the fallacies of using FLOATs. I personally think one should not use FLOATS unless one fully understands the (dis)advantages.
I once had an Oracle developer use FLOATS in an interim step to translate monetary values from a text source to a decimal destination. He was then wondering why his numebrs were always off of $0.01. took him a while to get the concept that the computer introduced imprecision into his process.
| cj |
| (MM club member) |
| 2008-05-06 01:49 AM |
|
|
|
Re: DateDiff, DateAdd
|
I tend to agree and have had all manner of trouble dealing with DateTimes. You can't just trust = and <> to compare times, you have to say Abs(T1-T2)<00:00:00.001 means =.
What century is this, where's my quantum computer!?
cj
| Skatterbrainz |
| (Starting to like KiXtart) |
| 2009-01-03 11:15 PM |
|
|
|
Re: DateDiff, DateAdd
|
Getting back to the original question I posted: I was looking at how other languages have reached a point where certain "standard" functions have been incorporated into the base scripting engine because they had become so widely used. Things like string manipulation, date and time functions, math and statistical operations, and in some cases database interface tools. It seems to me that date and time functions are pretty common and that maybe it's a good time to consider rolling at least two into the "core": DateDiff() and DateAdd(). I understand some would disagree, but this is the "suggestion" forum, so I'm just making a suggestion.