Ashley Yakeley wrote:
* Can we assume that gettimeofday always returns UTC rather than TAI time?
POSIX says yes. People might set it differently, but there doesn't seem to be any way of detecting that.
I'd like to mention a technique that doesn't seem to have been suggested yet: we can probe the configuration of the user's system at run time by calling gmtime and friends with preselected arguments. In particular, the value of, say, gmtime(80000000)->tm_sec should suffice to distinguish between the following three cases: * time_t is TAI (atomic seconds since TAI epoch) and gmtime returns UTC (with leap seconds) * time_t is UTC (atomic seconds since UTC epoch) and gmtime returns UTC (with leap seconds) * gmtime is not leap-second aware In the third case I think it's sensible to assume that gmtime returns UTC +/- one second, since gmtime's output (modulo 15 minutes) is what the user will actually see, and if it's off by 20+ seconds, either they'll fix it, or they don't care what second it is and neither need we. From that we can derive an approximate TAI (and seconds-since-UTC-epoch) using an internal table of leap seconds. In the other two cases we can use one more gmtime call to test whether the system's leap-second table is at least as current as ours, and use either the system's or ours depending on that. I don't know if the first case actually occurs in the wild. The second case does occur on Linux systems which link /etc/localtime to something under /usr/share/zoneinfo/right/. Those people clearly care about accurate timekeeping and we should do what we can to cater to them. This site was helpful: http://www.thedjbway.org/clockspeed/leapsecs.html -- Ben