time since the epoch
10 Feb 2003 10:15:02 -0800
SM> TimeDiff isn't a "duration", it's a way of specifying time offsets =
SM> duration depends on the base to which the offset is being added. I=
SM> only had constant-duration offsets, then there would be no way to s=
SM> "give me a ClockTime for this time next Wednesday".
[nitpicking] Oops, this is not the purpose stated in the library report:
"The TimeDiff type records the difference between two clock times in a
Anyway, the sort of specification that you are talking about is really
a pain IMHO. Actually, you could not use TimeDiff to state it,
either. [ISO8601 allows it but I think it's too imprecise to be useful]
SM> The problem is really that all the different kinds of offset are lu=
SM> into one type: there ought to be a TimeDiffSeconds, TimeDiffMonths,=
SM> so on. TimeDiffSeconds is a constant-duration offset, but
SM> TimeDiffMonths isn't. The problem with lumping them into one type =
SM> that if multiple components are non-zero, you don't know in which o=
SM> to add them.
It is always a problem to lump things with different semantics into
the same type :-) What I'm arguing is that there should be only one
fixed-duration offset datatype and it should be in terms of (seconds,
Other fixed durations can be easily defined in terms of this
I'm still not sure that you actually want base-dependent offsets, but
again they can be easily defined on top of the fixed duration
datatype. And they should be specified separately from the base
Certainly, differences between clock times should be in terms of the=20
SM> The TimeExts library gives you separate differences like
SM> these, BTW.
That sounds good, I'll look at it again (it's pretty much bare code,
so I might have overlooked something).
>> Unfortunately, with UTC, this goes on to make adding *anything* exce=
>> 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 perfect=
>> legal UTC time on a day with a leap second) meaningless.
SM> That's right, and here I'm not sure whether the right behaviour is =
SM> raise an exception or to "roll over" to the next nearest date/time.=
SM> believe TimeExts does some kind of rolling over, but I'm not sure o=
SM> exact semantics (George?).
As far as I read ISO8601 (which also has a notation for durations)
this is unspecifed :-) And as far as I read TimeExts.lhs it does some
sort of rollover. My take would be to specify the behavior for adding
something like a TimeDiff to a base date in a consistent manner and
then cast that in stone. If there is a (reasonable) standard for this
kind of calculation, then this should be the basis for the specification.
SM> Ok, ISO8601 seems to specify only constant-duration time intervals,=
SM> allows them to be given in terms of years, months, days etc., where=
SM> month is specified to be 30 days, it seems, and similar
If I remember correctly, then ISO8601 specifies durations up to a day,
but bails out at months and years.=20
>> Agreed! So what is epoch? Is it
>> "Seconds since 00:00:00 on 1 Jan 1970 [TAI]"?
SM> I guess so... GHC's implementation will be whatever the C library u=
SM> which I assume is the one you specified above (at least on a decent
Unfortunately, if you are using time(2), then you'll get rubbish (from
the manual page):
time returns the time since the Epoch (00:00:00 UTC, Jan=AD
uary 1, 1970), measured in seconds.
POSIX.1 defines seconds since the Epoch as a value to be
interpreted as the number of seconds between a specified
time and the Epoch, according to a formula for conversion
from UTC equivalent to conversion on the na=EFve basis that
leap seconds are ignored and all years divisible by 4 are
leap years. This value is not the same as the actual num=AD
ber of seconds between the time and the Epoch, because of
leap seconds and because clocks are not required to be
synchronised to a standard reference. The intention is
that the interpretation of seconds since the Epoch values
be consistent; see POSIX.1 Annex B 2.2.2 for further
The problem is that this notion of time is discontinuous and sometimes
not strictly increasing. See the various references pointed out by
members of the list for why this can be a problem.
PS, I see you are trying to follow-up to haskell-cafe, but I'm not
subscribed to that list.