[LEAPSECS] presentations from AAS Future of Time sessions

[Warner Losh]

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.


> 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.


> 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 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"


> 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.


> Note:

> The last three terms of the expression add in a day for each year that 

> follows a leap year starting with the first leap year since the Epoch. 

> The first term adds a day every 4 years starting in 1973, the second 

> subtracts a day back out every 100 years starting in 2001, and the 

> third adds a day back in every 400 years starting in 2001. The 

> divisions in the formula are integer divisions; that is, the remainder 

> is discarded leaving only the integer quotient.

> 

> 

> History:  <http://en.wikipedia.org/wiki/Unix_time>

> 

> Joe Gwinn  

> _______________________________________________

> LEAPSECS mailing list

> LEAPSECS at leapsecond.com

> http://six.pairlist.net/mailman/listinfo/leapsecs