Time

[Peter Simons]

Bayley, Alistair writes:

 > I assume that the only reason we can't establish a
 > mapping between 2043-04-01T00:00:00 and TAI is because of
 > the leap seconds problem. [...]

I am no expert either, but that's how I understood it. TAI
is perfectly accurate, but all other time systems make
unpredictable jumps to accommodate the changes in earth
rotation speed.


 > My point was that when you say "here is a time, specified
 > as x", where x is one of TAI / UTC / Julian+TZ /
 > Gregorian+TZ / etc, any of the x's is as good as any
 > other (as long as the time is not in the future), and the
 > internal representation of time could be any one of, or
 > none of x.

I think that's true, but not being able to express a date in
the future is a rather serious limitation, IMHO. If you want
to do that (and you do), then not all time systems are
equally good.

A bank, for example, can't store its financing data in TAI,
because TAI knows only the difference between two points in
time. Between now and some day in the future, exactly 'n'
seconds will pass. If that day is in the sufficiently
distant future though, your mortgage repayment won't be due
on April 1st some year, but on March 31st a second before
midnight. Therefore these applications really need to store
_calendar time_, which would be UTC et all.

You can map TAI to calendar time iff that date is in the
past or in the near future. (I think leap seconds are
announced at least a year before they occur or so.) That
makes TAI unsuitable as an internal representation for most
applications.


 > Assuming milliseconds (is this reasonable?):

IMHO, a good choice to store distance in time is:

  type TimeDiff = (Integer, Float)

That would be seconds plus a fraction of a second. Most
people really just need seconds, so binding it as (ts,_)
will do nicely, and those that need more granularity have
arbitrary precision -- theoretically.

Maybe this is even better?

  data Timestamp = forall a. Fractional a => TS Integer a

Peter