Re: Time Libraries Rough Draft

On Sat, Feb 12, 2005 at 05:14:44PM -0800, Ashley Yakeley wrote:

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

I don't mind providing these too, but providing a getLeapSecondsTable :: IO LeapSecondsTable that does the best thing is still a very good idea for a few reasons. * The whole point of a common library is to abstract this sort of thing. * It is always possible to determine a 'best' LeapSecondTable, unlike multiple time sources, where choosing among them is hard, a leap second table is a perfectly well defined with with a _total ordering_ on how good they are, namely the date to which they are valid. When you have multiple leap second table sources, the best thing to do is obviously choose the one which has the latest 'valid' date. No matter how many alternate choices we provide, each rational user will end up writing a routine to do just this comparasin, we might as well provide a function to do it for them :) * It is entirely possible POSIX or glibc will be extended with real standard routines for querying a table, It would be a horrible shame if all that code out there that felt they had to hard-code their own LeapSecondTable getting routines to depend on libtai or some other hack didn't automatically take advantage of it. * There are no reliability issues if the LeapSecondTable contains the date to which it is valid. The user is always aware of when a conversion is based on possibly out-of-date info and can take appropriate action. * Behavior hard-coded in a library binary is better than behavior hard-coded by arbitrary user code. only a single point of change. users are always free to create LeapSecondTables via other means for whatever reasons but asking for the 'systems best' will be by bar the more common choice. right now I am thinking something like type MonthYear = (Month,Int) data LeapSecondTable = LeapSecondTable { validDate :: MonthYear, leapSeconds :: [(MonthYear,Int)] } (or an abstract type with appropriate querying and construction routines since we will probably want an internal optimized form for said table) John -- John Meacham - ⑆repetae.net⑆john⑈