Re: Time Libraries Rough Draft

On Sat, Feb 12, 2005 at 05:34:35AM -0800, Ashley Yakeley wrote:

In article <7DFF3BC6CA957441AEADA7F340BFAA340A029353@GBLONEX11.lon.invesco.com>, "Bayley, Alistair" wrote:

...

...

The problem is that it has been stated several times on this thread that there will be no leap second table, nor a way to use one.

That's not my understanding (but then I do fid it hard to follow _everything_). Ashley's proposed API has the following:

module System.Time.LeapSeconds ( ... ) where ... utcDayLength :: LeapSecondTable -> JulianDay -> DiffTime utcToTAITime :: LeapSecondTable -> UTCTime -> TAITime taiToUTCTime :: LeapSecondTable -> TAITime -> UTCTime

Of course, where the LeapSecondTable comes from is another problem...

Exactly. There will be no complete leap second table provided (since that's not possible) or even up-to-date table (since we don't have an API for that), but there will be a type for it and you will be able create and use them from information you may have.

There should definitely be a getLeapSecondTable :: IO LeapSecondTable which will do its best on a given system to get the leap second table. It is not like it is hard to synchronize a leapsecond table, and systems that natively support TAI can always provide an up to date one, I'd also like to see a getTAITime :: IO TAITime which will do its best to get the current TAI time (subject to system interfaces). which may be just converting from POSIX time with the most up-to-date leap second table, but very well might do something better on some systems. It is important that the LeapSecond table have both a listing of leap seconds AND a date to which it is known valid. (the last leap second was quite a bit ago, but the table is well defined to a bit in the future of now) This will allow the TAI conversion routines to let you know when they are approximate or exact. I am not sure why some people seem convinced that a leap second table is that hard to get, It is certainly no harder a problem to solve than synchronizing time in the first place. plausable (cruddy, but okay on raw POSIX) implementations for both are getTAITime = do ls <- getLeapSecondTable ct <- getCurrentTime return $ utcToTAITime ls ct getLeapSecondTable = do handle (\_ -> return builtInTable) $ readFile "/etc/leapseconds" >>= return . readLeapSecondTable builtInTable = ... readLeapSecondTable = ... Ideally, the conversion routines would return times along with a boolean representing whether the conversion was exact. The reason why a getTAITime is needed that is separate from getLeapSecondTable is that it is perfectly plausable for a system to have only a TAI clock (think a cesium clock, or a non-network synchronized clock that clicks at a given rate) but no leap second table. This is even a _very_ likely configuration on embedded devices. With these additions, I like the proposal modulo a few name changse. like System.Time.LeapSeconds is a misnomer, TAI is not any more related to leap seconds than UTC is, in that LeapSecondTable is what is used to convert between the two but each can be used effectively and usefully alone without reference to said tables. I also would prefer the types being instances of Integral rather than having a bunch of special operations. John -- John Meacham - ⑆repetae.net⑆john⑈