# Concerning Time.TimeDiff

Graham Klyne GK@ninebynine.org
Fri, 20 Jun 2003 17:45:00 +0100

```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

```