[LEAPSECS] presentations from AAS Future of Time sessions

[Joseph Gwinn]

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