Concerning Time.TimeDiff

[Simon Marlow]

Graham Klyne writes:=20
> Whatever we may decide about TimeDiff values, I think this=20
> indicates that a=20
> clocktime should *not* be a single integer.  The minimal=20
> representation=20
> that avoids getting dragged into leap-second issues would=20
> seem to be, e.g.,=20
> a pair of Integers (days and picoseconds).

I'm afraid I don't see why this is necessary.  The definition of
ClockTime and TimeDiff in terms of TAI *is* independent of leap seconds:
it is the conversion to/from CalendarTime that involves leap-second
calculations. =20

> This also leaves me thinking that, completely aside from=20
> efficiency issues,=20
> that a TimeDiff should also be expressed in days and=20
> sub-days.  I have two related reasons for this:
>=20
> (1) the point that I made previously that adding a TimeDiff=20
> of an exact=20
> number of days to a Clocktime should always result in a new=20
> Clocktime that=20
> yields the exact same time-of-day.

This would be provided for in the new library as the function addDays:
see the OPTIONAL section at the end.

> (2) I assert that ct+dt  (ct::ClockTime, dt::DiffTime) should=20
> always yield=20
> the same answer for any giver ct and dt.  If dt is expressed=20
> only as a=20
> sub-day value (e.g. picoseconds) then the actual value=20
> depends on whether=20
> there is a leap second in the time interval [dt,dt+ct).  But=20
> the occurrence=20
> of leap seconds is not known very far into the future, so if=20
> you try to=20
> take account of leap seconds you may end up with different answers=20
> depending on the state of knowledge at the time the calculation is=20
> performed.  Ugh!

I think I see what you're trying to do, but I don't think it's
necessary.  In the TAI proposal, you can do calculations on ClockTimes
to your heart's content at arbitrary times in the future, and no
accuracy is lost to unknown leap seconds.  The only time accuracy would
be lost is if you want to convert the ClockTime to a UTC-offset
CalendarTime.

Alternatively, you can do calculations on CalendarTimes at arbitrary
points in the future without losing any accuracy (using the proposed
addDays, addMinutes, etc.).  HOWEVER, you can't accurately use
addSeconds or addPicoseconds on a CalendarTime in the future without
knowing where leap seconds occur.  This is an interesting bug/feature
that I just realised.

Cheers,
	Simon