System.Time.Clock Design Issues
ashley at semantic.org
Thu Feb 3 20:48:28 EST 2005
In article <200502040024.46434.benjamin.franksen at bessy.de>,
Benjamin Franksen <benjamin.franksen at bessy.de> wrote:
> 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
More information about the Libraries