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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
!DSPAM:4202c11e28858748444101!