Time Libraries Rough Draft

[John Meacham]

On Sat, Feb 12, 2005 at 05:14:44PM -0800, Ashley Yakeley wrote:
> In article <20050212150528.GH4062 at momenergy.repetae.net>,
>  John Meacham <john at repetae.net> 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⑈