[LEAPSECS] presentations from AAS Future of Time sessions

Joseph Gwinn joegwinn at comcast.net
Sat Jan 11 13:16:35 EST 2014


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


More information about the LEAPSECS mailing list