System.Time.Clock Design Issues

[Seth Kurtzberg]

I had a thought on the leap second issue.

I noticed that on an NIST web site, you can obtain not only the leap 
seconds to date, but also the scheduled leap seconds for several years 
into the future.  Using this table would almost project you from an out 
of date leap second table.

This would eliminate the problem of the table becoming out of date, 
because future leap seconds would also be in the table.  It's not a 
perfect solution, as in rare cases an additional leap second is added 
(one that does not appear on the schedule of future leap seconds).  Even 
so, it is highly likely to be correct about future leap seconds, so the 
library is highly likely to be correct (w.r.t. leap seconds).

Someone suggested applying the leap second table as an argument.  If the 
scheduled leap second table is built into the system, that argument 
could, instead, identify any leap seconds that for some reason were not 
on the schedule.

I'd be inclined to use the table, with past and scheduled leap seconds, 
and worry about modifications to the table later, since the odds are 
that such modifications won't occur.

Keean Schupke wrote:

> Peter Simons wrote:
>
>> Benjamin Franksen writes:
>>
>> > What about making the leap seconds table (LST) a
>> > parameter of the UTC/TAI conversion?
>>
>> That is definitely a good idea. If I didn't get it wrong,
>> then any TAI to Calendar Time conversion needs this
>> information to be accurate:
>>
>> * TAI time to convert,
>> * TAI time when the above timestamp was created,
>> * and the table of leap seconds in TAI.
>>
>> This is the only way a TAI timestamp into the future can be
>> converted back to Calender Time accurately -- at all points
>> in time. Or so I believe.
>>
> If the system provided the current time as either UTC or TAI, would
> there be any application that would need to convert between the
> two?
>
>    Keean.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
> !DSPAM:4202c11e28858748444101!
>