System.Time.Clock Design Issues

[Ben Rudiak-Gould]

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