Time Libraries Rough Draft

[John Meacham]

On Sat, Feb 12, 2005 at 05:34:35AM -0800, Ashley Yakeley wrote:
> In article 
> <7DFF3BC6CA957441AEADA7F340BFAA340A029353 at GBLONEX11.lon.invesco.com>,
>  "Bayley, Alistair" <Alistair_Bayley at ldn.invesco.com> 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⑈