RE: Concerning Time.TimeDiff

Graham Klyne writes:
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).
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.
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.
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 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!
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

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. Similarly, converting between ClockTime and CalendarTime in time zones with daylight savings is somewhat unpredictable. In my time zone, the determination of when to set clocks ahead has changed a couple of times in
On Monday 23 June 2003 05:35, Simon Marlow wrote: the past 20 years. I wouldn't want the API made more complex in order to accomodate these uncertainties.
participants (2)
-
Scott Turner
-
Simon Marlow