Time Library Organisation
wnoise at ofb.net
Thu Jan 27 14:41:14 EST 2005
On 2005-01-27, Simon Marlow <simonmar at microsoft.com> wrote:
> On 27 January 2005 17:06, Daan Leijen wrote:
>> 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:
>>> DJB (the author of libtai) disagrees with POSIX about what
>>> gettimeofday should return, and assumes that it actually returns
>>> what he wishes it returned.
More accurately, he expects admins to set it to TAI, and not run
programs that set it to other than non-TAI.
>> Wow, that is terrible! Well, we can not fix libraries. If libtai is
>> that broken, we can just as well do it ourselves:
> That's pretty much the conclusion I came to when I looked at libtai for
> implementing my library.
The thing is that POSIX or not, storing UTC in a time_t is clearly
broken. There are people working on systems that store TAI (or TAI +
fixed offset) in time_t, with special NTP daemons or patches to the
standard ones. I would really like the ability to have Haskell programs
do exactly the right thing in such an environment.
This can't be autodetected, short of a network probe of a timeserver
though, and even that will just be a heuristic. The only way to fix
this is to let people explicitly tell the library that they're on such
It'd be convenient if there were, say, environment variables defined for
this purpose. (Or another convenient system. A file would be fine too,
but I think environment variable would involve the least overhead.)
> You can't assume that time_t is not being adjusted for leap seconds: the
> host might be running NTP, for example. The best thing to do seems to
> be to assume that time_t is a count of seconds since the epoch minus
> leap seconds, and calculate TAI from that. It might be wrong by up to a
> second around a leap second on a host running NTP, and slightly more
> wrong on a host not running NTP, but the latter probably don't care too
> much about second-accuracy anyway.
Certainly the best default at this time.
More information about the Libraries