System.Time.Clock Design Issues

[Ashley Yakeley]

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