At 13:37 19/06/03 +0100, Simon Marlow wrote:
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.
I think this is an important point, and thanks for pointing it up. Whatever we may decide about TimeDiff values, I think this indicates that a clocktime should *not* be a single integer. The minimal representation that avoids getting dragged into leap-second issues would seem to be, e.g., a pair of Integers (days and picoseconds). This also leaves me thinking that, completely aside from efficiency issues, that a TimeDiff should also be expressed in days and sub-days. I have two related reasons for this: (1) the point that I made previously that adding a TimeDiff of an exact number of days to a Clocktime should always result in a new Clocktime that yields the exact same time-of-day. (2) I assert that ct+dt (ct::ClockTime, dt::DiffTime) should always yield the same answer for any giver ct and dt. If dt is expressed only as a sub-day value (e.g. picoseconds) then the actual value depends on whether there is a leap second in the time interval [dt,dt+ct). But the occurrence of leap seconds is not known very far into the future, so if you try to take account of leap seconds you may end up with different answers depending on the state of knowledge at the time the calculation is performed. Ugh! #g ------------------- Graham Klyne <GK@NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E