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