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