Concerning Time.TimeDiff

[Simon Marlow]

> Well, my main problem with representing time as a pair, is that a
> point in time isn't uniquely defined (e.g. should it be 3s + 5e-11ps,
> or 2s + 5e-11ps), and that, in most suggested formats, they overlap
> (e.g. 3s or 2s + 1e12 ps).  So you need to normalize -- possibly after
> each operation.  Are you sure this is more efficient than using
> bignums?=20
>=20
> Further, I'm not sure Haskell has a standard 64 bit Int.  I'm fairly
> sure it's in GHC, and probably in the other compilers, but it'd be
> nice if it were in the standard.  On the other hand, Integer can be
> implemented any way that's efficient on each architecture.

Haskell does have a standard 64 bit Int, known as Int64.  (standard in
the sense that the FFI addendum defines it, which is almost but not
quite as standard as Haskell 98).

If there are performance concerns, then we should measure both the
version with an Int64 pair and the version with Integer.  My guess is
that there won't be enough of a difference for it to matter.

> > I find it hard to lose sleep over missing leap-seconds and=20
> dates beyond
>=20
> Leap seconds are a completely orthogonal issue.  From the discussion
> here, it seems plain that UTC is a kluge, and TAI is the way to go.
> In any case, we already agree to counting seconds, the question is how
> to count them :-)

UTC is only a kludge for the fact that the Earth wobbles a bit on its
trajectory through space - I think that's a reasonable kludge :-)

POSIX "seconds since the epoch" is a *real* kludge.  Let's not get the
two confused.

Cheers,
	Simon