New definition of "Seconds Since the Epoch" in POSIX
The new 2001 edition of the POSIX standard (IEEE Std 1003.1-2001) is now freely available online: http://www.UNIX-systems.org/version3/ Of particular interest to all you leap second gurus out there is perhaps the new slightly revised/relaxed definition of the technical term "Seconds Since the Epoch" that forms the basis for the scalar time used in Unix system calls: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_0... A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time are made is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. What has changed? Apart from adding the mod 100 years and mod 400 years leap year rules to the formula, the last two paragraphs have been added. These essentially relax the definition of Seconds Since the Epoch. Without them, a strict interpretation of the old definition would have required that a UTC-aware implementation (e.g., an NTP-synchronized workstation) has to show the same progression of values during an inserted leap second 23:59:60Z and the following first second of the next day 00:00:00Z. In other words, the wording of the old definition could have been interpreted to require UTC-synchronized POSIX clocks to show the same scalar timestamp at 23:59:60.5Z as well as one second later at 00:00:00.5Z, which is indeed what for example the Linux kernel did when connected to a reference clock with activated kernel PLL. The new definition relaxes that and allows for example an implementation to decide to implement the progression of the scalar system time near an inserted leap second by slowing down the system clock briefly, for example according to the formula proposed in http://www.cl.cam.ac.uk/~mgk25/uts.txt As I read it, the new definition still prevents implementations from making the system's scalar time an exact measure of physical time (e.g. by applying the provided encoding formula to a TAI clock display, instead of a UTC clock display) by the requirement of representing each day by an increment of 86400 "seconds" on the scalar clock. (Though nitpickers could of course argue that the text does not explicitely refer to a UTC day, I know :-) Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
Date: Thu, 07 Feb 2002 18:05:43 +0000 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
The new definition relaxes that and allows for example an implementation to decide to implement the progression of the scalar system time near an inserted leap second by slowing down the system clock briefly.
Yes, and the POSIX 1003.1-2001 rationale is even more explicit than the official standard on this point. Here's a quote from <http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap04.html#tag_01_04...>: It is a practical impossibility to mandate that a conforming implementation must have a fixed relationship to any particular official clock (consider isolated systems, or systems performing "reruns" by setting the clock to some arbitrary time). Note that as a practical consequence of this, the length of a second as measured by some external standard is not specified. This unspecified second is nominally equal to an International System (SI) second in duration. Applications must be matched to a system that provides the particular handling of external time in the way required by the application. Also, the POSIX editors went through the standard and replaced most instances of the phrase "seconds since 00:00:00 UTC (Coordinated Universal Time), January 1 1970" with "seconds since the Epoch". I think it's clear that the intent was that a POSIX system could use UTS <http://www.cl.cam.ac.uk/~mgk25/uts.txt> rather than UTC.
As I read it, the new definition still prevents implementations from making the system's scalar time an exact measure of physical time (e.g. by applying the provided encoding formula to a TAI clock display, instead of a UTC clock display) by the requirement of representing each day by an increment of 86400 "seconds" on the scalar clock.
I don't see why that requirement prohibits a system with a TAI time_t that has 86400 seconds per day. Suppose we make the usual assumption that the TAI time_t and UTC time_t values are identical on 1972-01-01, which means the two time_t values differ by 22 seconds now. Then, on a TAI-based system, "date -u" would output "Thu Feb 7 23:24:22 UTC 2002" at the same time that that a conventional UTC-based system would output "Thu Feb 7 23:24:00 UTC 2002". As I see it, that's consistent with the intent of the new standard. POSIX does require that gmtime use an 86400-second day, and that gmtime must return UTC, and I think this does prohibit a system that uses TAI time_t. However, this gmtime requirement seems to prohibit UTS time_t as well, and I don't think this was intended. POSIX 1003.1-2001 is a large new spec, with quite a few bugs (e.g. <time.h> allows tm_sec to be 60, which means it does allow leap seconds!), so it wouldn't be surprising if some interpretation requests were needed to shake out some of the problems here.
Paul Eggert wrote on 2002-02-07 23:44 UTC:
POSIX 1003.1-2001 is a large new spec, with quite a few bugs (e.g. <time.h> allows tm_sec to be 60, which means it does allow leap seconds!), so it wouldn't be surprising if some interpretation requests were needed to shake out some of the problems here.
Standardization is a slow process. Remember how many years it took us to get the upper limit of tm_sec from 61 to 60? :) Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
participants (2)
-
Markus Kuhn -
Paul Eggert