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