Time Library Organisation

[Aaron Denney]

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: 
>>> 
>>> [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.

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
a system.

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.

-- 
Aaron Denney
-><-