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⑈

On 2005-02-12, John Meacham wrote:

getLeapSecondTable = do handle (\_ -> return builtInTable) $ readFile "/etc/leapseconds" >>= return . readLeapSecondTable

libtai uses (${PREFIX})/etc/leapseconds.dat the Time Service of the US Naval Observatory provides one at ftp://maia.usno.navy.mil/ser7/tai-utc.dat It would be nice if we could use one of those formats rather than creating yet another one. -- Aaron Denney -><-

In article <20050212150528.GH4062@momenergy.repetae.net>, John Meacham wrote:

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.

Doing this sort of "whatever's best" has problems. We have to provide a single library that people will compile in to their programs, and a single binary may run on systems with different resources available. I'd rather give users the tools they need to get the table or to get TAI in explicit ways, rather than doing a bunch of unknown stuff such as file access behind the scenes. This way people can come up with their own strategies for the kind of reliability they need. Something like this, perhaps: parseLeapSecondTableFromUSNO :: ReadS LeapSecondTable parseLeapSecondTableFromLibTAI :: ReadS LeapSecondTable getLeapSecondTableFromLibTAI :: FilePath -> IO LeapSecondTable -- Ashley Yakeley, Seattle WA