Concerning Time.TimeDiff

[Graham Klyne]

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