time since the epoch

[Stefan Karrmann]

Peter Thiemann (Fri, Feb 07, 2003 at 10:22:12AM -0800):
> >>>>> "SM" == Simon Marlow <simonmar@microsoft.com> writes:
>     SM> This isn't a problem with the spec, I think.  A TimeDiff of "1 month" is
>     SM> precisely a difference, which, when added to a given ClockTime, produces
>     SM> a ClockTime which is one month later (with respect to some timezone,
>     SM> presumably UTC since it isn't specified otherwise).  That is, January
>     SM> 12th 12:00 UTC becomes February 12th 12:00 UTC, and so on.  Adding one
>     SM> month to certain ClockTimes is meaningless: eg. adding one month to
>     SM> January 31st doesn't work.
> 
> Unfortunately, with UTC, this goes on to make adding *anything* except
> seconds to certain ClockTimes (namely the instants of leap seconds,
> eg, what happens if you add 1 minute to 23:59:60 ? This is a perfectly
> legal UTC time on a day with a leap second) meaningless. My take would
> be to look at an established standard for expressing time durations
> (eg, ISO8601) and just adhere to that (but not the POSIX standard,
> please!). Personally, I think that it is unacceptable to make
> something like addToClockTime a partial function.

IMHO, you need two different functions to add time. One that add the
absolute time difference (as TAI seconds). Another one add calendar
times and rounds down as needed, e.g.

(timediff calTime1 calTime2) :: TimeDiff (in years, months, etc.)

floorTimeAdd '2000-01-31' (Month 1) == '2000-02-28'
floorTimeAdd '2004-01-31' (Month 1) == '2000-02-29' -- a leap year

Suppose a leap second:
floorTimeAdd '2000-01-31.23:59:60' (Minute 1) == '2000-02-01.00:00:59'


Cheers,
-- 
Stefan Karrmann