Peter Simons
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.
The flip side of the coin is of course being unable to specify time differences with certainity in the future.
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.
I think the bank should use a system that lets it specify, in an unambigous way, days, if that's what matters. Counting seconds shouldn't be a matter of concern. So we need two systems, and if the correspondence between them (e.g. which_day_is_this :: Time -> CalendarDay) gives the wrong answer for a second for people who update their systems more rarely than once a year, well, they get their interest (or mortgage) one second late in the worst case.
Therefore these applications really need to store _calendar time_, which would be UTC et all.
I don't think UTC seconds is the right thing either, but some real calendar type. I would like to specify "the first day of each month", not intervals of x seconds, y seconds, then x seconds again...
Assuming milliseconds (is this reasonable?):
IMHO, a good choice to store distance in time is:
type TimeDiff = (Integer, Float)
It would perhaps be nice if the interface provided a way to determine the resolution of the timer -- a guarantee of a minimum value of change, I guess. -kzm -- If I haven't seen further, it is by standing in the footprints of giants