• Well, since dates are stored as floating point numbers, it can have those problems, but there isn't a way around that if you're using datetime data. And it should only have errors in the milliseconds measure.

    Is there some specific situation you were thinking of? The things I've tested it on seem to be correct. I haven't use this, just thought it was an interesting calculation and might work here.

    Where it can have problems is if you input the dates backwards and subtract a later date from an earlier date. If you can't protect against that, then it's important to use ABS on the date subtraction.

    It does have some intersting issues, now that I test it a bit more. For example, I used 1 Jan 1800 and 1 Jan 1901 as the dates, and it came back as 100 years, 12 months, 31 days, 0 hours, 0 minutes, 0 seconds, 0 milliseconds.

    If I modify it to have -1 on the month and day, it gives accurate counts. Hadn't taken into account that Jan != 0. With that correction, it fixes the 100 years, 12 months, 31 days, problem.

    With that correction, I just tested it on a few dozen dates, and it was right in each case.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon