time since the epoch
Simon Marlow
simonmar@microsoft.com
Fri, 7 Feb 2003 13:38:03 -0000
> Ha! After playing with this, I discovered that only the seconds were
> set and all other fields remained untouched. At least in ghc's
> implementation. Interestingly, TimeDiff derives Eq and Ord, but I'd
> better not ask for their implementation...
TimeDiff has a perfectly well-defined meaning for Eq and Ord: one
TimeDiff is equal to another iff all the fields are respectively equal.
See
http://www.haskell.org/pipermail/haskell-cafe/2002-December/003758.html
> There is also a more fundamental problem with the TimeDiff data
> type. While seconds, minutes, hours, and days are clearly specified
> amounts of time, the duration of a month or a year may vary depending
> on the reference point where the time difference is applied.
This isn't a problem with the spec, I think. A TimeDiff of "1 month" is
precisely a difference, which, when added to a given ClockTime, produces
a ClockTime which is one month later (with respect to some timezone,
presumably UTC since it isn't specified otherwise). That is, January
12th 12:00 UTC becomes February 12th 12:00 UTC, and so on. Adding one
month to certain ClockTimes is meaningless: eg. adding one month to
January 31st doesn't work.
At least, that's how I believe it is supposed to work. GHC's
implementation *is* completely wrong (which is perhaps where some of the
confusion comes from), but the TimeExts library can be used instead of
TimeDiffs.
> My conclusion is that time differences really should be measured in
> seconds and picoseconds.=20
>=20
> type TimeDiff =3D (Integer, Integer)
We already have this kind of TimeDiff: just don't use anything except
the seconds and picoseconds fields.
I agree with John Meacham in that it ought to be possible to get a raw
time in terms of seconds/picoseconds since the epoch, and indeed GHC
lets you do that: importing System.Time lets you get at the
representation of ClockTime:
data ClockTime
=3D TOD Integer -- Seconds since 00:00:00 on 1 Jan 1970
Integer -- Picoseconds with the specified second
This is a perfectly reasonable definition of absolute time, we don't
need to talk about TAI at all, except to define what the epoch means.
Cheers,
Simon