On Sat, 11 Jan 2014 10:39:32 -0700, Warner Losh wrote: > > On Jan 11, 2014, at 9:32 AM, Joseph Gwinn wrote: > >> On Fri, 10 Jan 2014 21:35:25 -0700, Warner Losh wrote: >>> >>> On Jan 10, 2014, at 8:35 PM, Skip Newhall wrote: >>> >>>> 'Proscribe’ and 'prescribe' are distinct words: >>>> >>>> 'Proscribe' means to forbid, disallow, or prohibit. “School rules >>>> proscribe the use of pencils on exams.” >>>> >>>> 'Prescribe' means to lay out specifications or rules about >>>> something. "In the manner prescribed by law.” >>>> >>>> I don’t know the context of the sentence the Magnus refers to. >>> >>> Prescribe is the word I intended. POSIX mandates, requires, >>> prescribes that time is UTC. >> >> No. While POSIX broken-down time resembles UTC, the underlying >> timescale (Seconds since the Epoch) is *not* UTC, in that every day >> contains exactly 60*60*24= 86,400 seconds. Leap seconds are *not* >> applied. > > That's the problem with POSIX time_t. It specifies a mapping from UTC > to time_t, but the mapping isn't 1-1 onto. It tries to be UTC, but > also tries to paper over leap seconds by pretending they don't exist. > That's part of the craziness of POSIX time_t. It specifies something > that doesn't match UTC, but is expected to be much like UTC. It also > is UTC in the sense that it tracks UT1 within a second (ignoring > errors in realization on a specific system). It is a poorly modeled > approximation of UTC that makes certain compromises to get a 'simple > math' property, but pretends that leap seconds don't exist and are an > implementation detail specifically not specified.
Trying to force POSIX time into the UTC mold isn't going to go well. Read the official definition slowly, without the assumption that the committee really meant UTC but didn't know how to say it. Every word was debated. See the appended section of Rationale. >> The confusion arises because the POSIX Epoch is defined using UTC. But >> the progression rule is a form of TAI (with unknown but constant >> offset). POSIX background information follows. > > The progression rule doesn't say that. The offset to TAI changes at > each leap second. So it is mostly kinda sorta TAI with a fixed > offset, until a leap second happens. Then the offset changes. The definition does not actually mention TAI (although it was proposed to do so). I'm just pointing out that POSIX time is in effect a form of TAI. Granted that the offset jumps on leap seconds if one is fed from UTC (via GPS), but this causes little trouble. If fed from GPS System Time, the offset never changes. >> URL of index page: <http://pubs.opengroup.org/onlinepubs/009695399/> >> >> >>> From POSIX Base Definitions volume: >> >> 3.149 Epoch >> The time zero hours, zero minutes, zero seconds, on January 1, 1970 >> Coordinated Universal Time (UTC). >> >> >>> From the General Concepts volume: >> >> 4.14 Seconds Since the Epoch >> 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 > > This section says UTC and defines how it is related to UTC... The key word is "related". This is not equality, and the choice of weasel word was deliberate. >> The relationship between the actual time of day and the current value >> for seconds since the Epoch is unspecified. > > This sentence is the most lame part of the spec. We define this > value, but it doesn't have to match? Most implementors I've talked > with have suggested that this means "the error is not bounded" rather > than "you can have random values second to second" There is a long history. It was a big fight. The trail is in the email archives, if anybody has the energy. Suffice it to say that the Time Folk kept quarreling about the One True Clock, while ignoring the needs of the POSIX world, until the POSIX Committee threw the Time Folk out in exasperation and stuck with what they had inherited from UNIX. I did manage to fix the leap year computation (restore the 400-year rule), and remove the nonsense about double leap seconds. Somewhere else, >> How any changes to the value of seconds since the Epoch are made to >> align to a desired relationship with the current actual time is >> implementation-defined. As represented in seconds since the Epoch, each >> and every day shall be accounted for by exactly 86400 seconds. > > This section says you are on your own for coping with leap seconds. > This allows all kinds of implementations, except one that assigns a > unique value to the leap second. It allows one to repeat a second > (either the last one of the day of the leap second, or the first one > of the next day (both common) or really any other second). It also > allows the google run a little fast until you accumulate the new > second. Yep. See above. In practice, most people that care about such things use GPS time delivered via NTP. In the radar systems of my experience, the GPS receiver is configured to emit GPS System Time (not UTC), and we just live with the offset between GPS System Time and UTC, or fix it locally where needed. There is more in the Rationale volume: A.4.14 Seconds Since the Epoch Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences. Broken-down POSIX time is therefore not necessarily UTC, despite its appearance. As of September 2000, 24 leap seconds had been added to UTC since the Epoch, 1 January, 1970. Historically, one leap second is added every 15 months on average, so this offset can be expected to grow steadily with time. Most systems' notion of "time" is that of a continuously increasing value, so this value should increase even during leap seconds. However, not only do most systems not keep track of leap seconds, but most systems are probably not synchronized to any standard time reference. Therefore, it is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch. It is sufficient to require that applications be allowed to treat this time as if it represented the number of seconds between the referenced time and the Epoch. It is the responsibility of the vendor of the system, and the administrator of the system, to ensure that this value represents the number of seconds between the referenced time and the Epoch as closely as necessary for the application being run on that system. It is important that the interpretation of time names and seconds since the Epoch values be consistent across conforming systems; that is, it is important that all conforming systems interpret "536457599 seconds since the Epoch" as 59 seconds, 59 minutes, 23 hours 31 December 1986, regardless of the accuracy of the system's idea of the current time. The expression is given to ensure a consistent interpretation, not to attempt to specify the calendar. The relationship between tm_yday and the day of week, day of month, and month is in accordance with the Gregorian calendar, and so is not specified in POSIX.1. Consistent interpretation of seconds since the Epoch can be critical to certain types of distributed applications that rely on such timestamps to synchronize events. The accrual of leap seconds in a time standard is not predictable. The number of leap seconds since the Epoch will likely increase. POSIX.1 is more concerned about the synchronization of time between applications of astronomically short duration. Note that tm_yday is zero-based, not one-based, so the day number in the example above is 364. Note also that the division is an integer division (discarding remainder) as in the C language. Note also that the meaning of gmtime(), localtime(), and mktime() is specified in terms of this expression. However, the ISO C standard computes tm_yday from tm_mday, tm_mon, and tm_year in mktime(). Because it is stated as a (bidirectional) relationship, not a function, and because the conversion between month-day-year and day-of-year dates is presumed well known and is also a relationship, this is not a problem. Implementations that implement time_t as a signed 32-bit integer will overflow in 2038. The data size for time_t is as per the ISO C standard definition, which is implementation-defined. See also Epoch. The topic of whether seconds since the Epoch should account for leap seconds has been debated on a number of occasions, and each time consensus was reached (with acknowledged dissent each time) that the majority of users are best served by treating all days identically. (That is, the majority of applications were judged to assume a single length - as measured in seconds since the Epoch - for all days. Thus, leap seconds are not applied to seconds since the Epoch.) Those applications which do care about leap seconds can determine how to handle them in whatever way those applications feel is best. This was particularly emphasized because there was disagreement about what the best way of handling leap seconds might be. 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. IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/12 is applied, making an editorial correction to the paragraph commencing "How any changes to the value of seconds ...". Joe Gwinn _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
