Time Library Organisation

Daan Leijen daan at cs.uu.nl
Thu Jan 27 12:05:30 EST 2005


Marcin 'Qrczak' Kowalczyk wrote:
> 
> You can't have gettimeofday() returning UTC and libtai returning TAI
> at the same time, because they return the same thing. This is the
> implementation from libtai:
> 
> [snip]
 >
> DJB (the author of libtai) disagrees with POSIX about what gettimeofday
> should return, and assumes that it actually returns what he wishes it
> returned.

Wow, that is terrible! Well, we can not fix libraries. If libtai is that 
broken, we can just as well do it ourselves: if we assume that we can 
convert a current UTC time to TAI, we can calculate the TAI time at the
start of the program and use time_t to keep track of the TAI delta -- 
here we take advantage of the time_t bug which is not adjusted for leap 
seconds!

About the assumption of converting current UTC to TAI:

>>(2) We can convert TAI to UTC (and back) up to half a year in the
>>future.
> 
> 
> Assuming that during the half of the year:
> - the Haskell compiler has been updated
> - and released
> - and installed where the given software will be compiled
> - and the software has actually been recompiled
> - and the program has been restarted (if it's running as a daemon)

Well, I would think that someone (?) distributes a table with leap 
seconds that is inspected by the library. We could maybe even install it 
as a separate package.

I think the key distinction between TAI and UTC (or calendars) is that
TAI is great for measuring time delta's, while UTC (and other calendars)
are good for marking specific "human times" -- and sometimes we have 
multiple markers for the same time (when a leap second occurs).

Given that TAI is best suited for time delta's, it might be good  to
define "monotonic" time like in scheme[1]. This is just SI-seconds, like 
TAI, but we leave the epoch unspecified. As such, the current "time_t" 
behaviour of unix (unadjusted for leap seconds) implements this. This 
means that monotonic time can do most of what TAI can do, but we can 
always provide it accurately.

-- Daan.

[1]
<http://download.plt-scheme.org/scheme/docs/html/srfi/srfi-19.html>


More information about the Libraries mailing list