Time Library Organisation

[Marcin 'Qrczak' Kowalczyk]

Daan Leijen <daan at cs.uu.nl> writes:

> (1) Implementation of TAI: On windows, the "FILETIME" is defined as
> 100 nano-second intervals after some epoch (1 Jan 1601 UTC). So, there
> is some basic atomic time available. On unix's we can use libtai.

> Implementation of UTC: On windows, the "SYSTEMTIME" supposedly gives
> UTC, on unix I believe that "gettimeofday" and friends supposedly give
> UTC

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:

void taia_now(t)
struct taia *t;
{
  struct timeval now;
  gettimeofday(&now,(struct timezone *) 0);
  t->sec.x = 4611686018427387914ULL + (uint64) now.tv_sec;
  t->nano = 1000 * now.tv_usec + 500;
  t->atto = 0;
}

and documentation:

NOTES
       This implementation of tai_now assumes that the struct timeval returned
       from gettimeofday represents the number of TAI seconds since 1970-01-01
       00:00:10 TAI.

DJB (the author of libtai) disagrees with POSIX about what gettimeofday
should return, and assumes that it actually returns what he wishes it
returned.

> (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)

Otherwise the process will disagree with the rest of the system by one
second.

Actually software which assumes that gettimeofday() returns TAI
already disagree with software which assumes that it returns UTC,
by some tens of seconds (depending on how they assume the Epoch).

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/