In article <200502040024.46434.benjamin.franksen@bessy.de>,
Benjamin Franksen
What about making the leap seconds table (LST) a parameter of the UTC/TAI conversion? The LST could be some abstract type, readable via an IO action either from the System (if future systems support this) or from some file. The point in time up to which the table is garanteed to be accurate should be a (queryable) property of the LST.
This would certainly be the best way to provide any kind of TAI support, given that TAI time is difficult to obtain from the system. I can think of two possible types for the table. Bear in mind leap-seconds can be both insertions and removals, though so far they've all been insertions. type JulianDay = Integer; -- day number type LeapSecondTable1 = JulianDay -> Int -- TAI - UTC on given day type LeapSecondTable2 = [(JulianDay,Int)] -- list of leap-seconds utcDayLength :: LeapSecondTable1 -> JulianDay -> Int utcDayLength lst d = 86400 + (lst (d + 1)) - (lst d); I rather prefer LeapSecondTable1. Either way, we could provide the table known at compile-time, or rather at compiler release time, however useful or not that may be: knownLeapSecondTable :: LeapSecondTable knownLeapSecondTableLimit :: JulianDay bestGuessLeapSecondTable :: LeapSecondTable The difference is that knownLeapSecondTable has no leap seconds after knownLeapSecondTableLimit, while bestGuessLeapSecondTable puts some in to keep track of the likely long-term difference as best it can. Again, I don't know how useful that is if it's going to become out of date a year or two after compiler release. If we did this sort of thing, we might consider putting TAI and leap-second handling into a separate module. -- Ashley Yakeley, Seattle WA