1. Do I correctly understand that, under this proposal, IERS expects the civil authorities to change the local time zone every few thousand years so that the sun is roughly overhead at 12:00? (Assuming, of course, that the world keeps using local time long enough for this to be an issue.) 2. To correct some information you've received about UNIX: UNIX does not keep track of time in UTC. UNIX keeps track of time as an integer (plus, in some cases, a 6-digit or 9-digit fractional part) that counts seconds. The bulk of UNIX time-handling software simply adds or subtracts these integers to schedule or measure real-time events. The popular Olson tz library in ``right'' mode interprets the counter as the number of TAI seconds since 1970-01-01 00:00:10 TAI, and converts it to local time for human display, taking account of leap seconds. It can also convert from local time back to the counter. Many applications call this library. Unfortunately, previous time libraries didn't understand leap seconds--- UNIX predates leap seconds!---and this mistake was codified in the POSIX standard, along with an incorrect leap-year rule. There are still some programs that produce silly results during leap seconds. But they'll be fixed eventually. 3. The tz library won't work past 2038. I've been writing a new library intended to work until the Gregorian calendar is replaced. This code will, of course, be easier to write correctly if there are no more leap seconds. ---Dan
"D. J. Bernstein" wrote on 1999-12-04 01:12 UTC:
2. To correct some information you've received about UNIX: UNIX does not keep track of time in UTC. UNIX keeps track of time as an integer (plus, in some cases, a 6-digit or 9-digit fractional part) that counts seconds.
Which - as you said later - is not what the POSIX standard says and it is also not what the NTP developers (or I) consider to be desireable, especially considering the current unpredictability of UTC-TAI and the current unavailability of TAI from most time broadcasting stations (GPS and Omega being the notable exceptions). Even though many Unix man pages describe the value returned by time() inaccurately as "time since 00:00:00 GMT, January 1, 1970, measured in seconds" the value is actually defined in POSIX.1 to be just a fixed encoding of UTC, and *not* a second count. This is also what NTP implementations do and what de-facto most Unix applications expect. It would become a second count only if UTC stopped to have leap seconds.
The bulk of UNIX time-handling software simply adds or subtracts these integers to schedule or measure real-time events.
The bulk of UNIX software also uses a fixed formula to break the time_t value down to a decomposed yyyy-mm-dd hh:mm:ss time. The standardized mapping of time_t to UTC in POSIX was essential, because numerous protocols (NFS, all the CORBA stuff, etc.) exchange time_t values or equivalent encodings across networks.
The popular Olson tz library in ``right'' mode interprets the counter as the number of TAI seconds since 1970-01-01 00:00:10 TAI, and converts it to local time for human display, taking account of leap seconds. It can also convert from local time back to the counter. Many applications call this library.
But almost nobody uses this "right mode", because it violates not only the POSIX definition of time_t, but also breaks numerous existing applications (causing a TAI-UTC error to show up in many distributed timestamps), right?
UNIX predates leap seconds!---and this mistake was codified in the POSIX standard, along with an incorrect leap-year rule.
Unix (like most all other OSes, except for a few special embedded real-time environments for avionics applications) started off with a somewhat naive clock model, and didn't provide for a distinction between a TAI and UTC clock. Once the distinction was established, the Unix community decided to go with the UTC clock and not with TAI, because the compatibility with time announcement services was deemed to be much more important than the occasional missing second in interval measurements. In many applications (especially service charging, financial transactions), it has now become a well-established tradition to not charge for leap seconds. This works remarkably fine in practice and allows you to use the naive subtraction on the encoded UTC timestamps to get the desired and (often even by contract!) agreed semantics. At least the power and telecoms industry is very happy to tolerate the 0.000002 % financial loss/gain made this way, as this is way below the rounding noise in their other accounting procedures. There are important process control, physical measurement and navigation applications, where sub-second interval time measurement is no doubt required. Traditional Unix, mainly due to its absence of a static-priority real-time scheduler, was never considered to be an environment suitable for these fields. Special POSIX real-time operating systems usually do have separate so-called "monotonic" time-scales. This is the reason, why the POSIX.1 clock_*() functions have a clock type parameter, because although only a naive clock type CLOCK_REALTIME is defined by POSIX.1:1996, the parameter is there to allow programmers to switch between the naive Unix wall-clock/UTC clock and other clocks with different trade-offs for interval measurements. There was a POSIX real-time group proposal to add a CLOCK_MONOTONIC clock type to the clock_*() functions a couple of years ago, but I don't know, what the current status of this it. It seems, that most of the POSIX group has broken up before these projects could be finished. In any case, I have taken up the ideas from this old POSIX proposal in http://www.cl.cam.ac.uk/~mgk25/c-time/ which is a proposal to add clock types with different trade-offs for real-time applications to the ISO C API. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
Date: 4 Dec 1999 01:12:56 -0000 From: "D. J. Bernstein" <djb@cr.yp.to> UNIX does not keep track of time in UTC. But POSIX specifies UTC, and the ideal internal POSIX clock matches the UTC clock. If the definition of UTC were changed, then POSIX's definition of time would change accordingly. It's common for confusion to arise in this area, because a common way to look at UTC is as a broken-down representation like 1998-12-31 23:59:60. These broken-down representations have always increased monotonically. But the official definition of UTC is based on TAI, and it is this definition that POSIX specifies for its internal clock. Since 1972 this clock has been adjusted backward by 1 second immediately after an inserted leap second, and therefore has counted TAI seconds except that it ignores completed leap seconds. The UTC clock is not monotonically increasing: it is ambiguous during an inserted leap second and the second thereafter. The common broken-down representation of UTC resolves this ambiguity by using ``:60'' to denote an inserted leap second, but the ambiguity is present in the UTC clock itself. The discrepancy between POSIX time and UTC time arises only in broken-down representations. POSIX makes no provision for leap seconds in broken-down representations, so clock ticks look like this near an inserted leap second: TAI-UTC TAI broken-down UTC broken-down POSIX broken-down 31 1999-01-01 00:00:30 1998-12-31 23:59:59 1998-12-31 23:59:59 31 1999-01-01 00:00:31 1998-12-31 23:59:60 1999-01-01 00:00:00 32 1999-01-01 00:00:32 1999-01-01 00:00:00 1999-01-01 00:00:00 32 1999-01-01 00:00:33 1999-01-01 00:00:01 1999-01-01 00:00:01 In practice, few (perhaps zero) POSIX hosts follow the POSIX definition exactly. Most fudge the issue by ignoring leap seconds, relying on manual intervention to adjust the clock eventually. Some hosts artificially lengthen seconds near an inserted leap second and skip the leap second, so that the internal clock continues to increase monotonically. A small number of not-quite-POSIX hosts use a TAI internal clock along with a UTC broken-down representation. All these solutions have drawbacks. If the definition of UTC were changed to use leap minutes rather than leap seconds, POSIX itself would not need to change. A table much like the above would apply, except that TAI-UTC would increase by 60, not by 1, and the POSIX broken-down representation would repeat a minute, not just a second. All the methods currently used to fudge leap seconds would apply to leap minutes too. However, I'm puzzled as to why the change is being proposed. Hosts are becoming better-connected, and this alleviates the hassle of updating leap-second tables, which as I understand it is the principal objection to leap seconds. If we go to a leap-minute regime we'll be facing a Y2k-like problem every century or so. Isn't it better to stick to the current regime of adjusting every year, so that the relevant software is tested more often?
participants (3)
-
D. J. Bernstein -
Markus Kuhn -
Paul Eggert