[LEAPSECS] presentations from AAS Future of Time sessions

[Joseph Gwinn]

On Sun, 19 Jan 2014 13:14:33 -0800, Brooks Harris wrote:

> On 2014-01-19 08:26 AM, Warner Losh wrote:

>> On Jan 18, 2014, at 11:03 PM, Brooks Harris wrote:

>> 

>>> On 2014-01-18 08:53 AM, Warner Losh wrote:

>>>> On Jan 18, 2014, at 6:31 AM, Magnus Danielson wrote:

>>>> 

>>>>> On 18/01/14 11:56, Poul-Henning Kamp wrote:

>>>>>> In message <52DA2A0F.9060704 at rubidium.dyndns.org>, Magnus 

>>>>>> Danielson writes:

>>>>>> 

>>>>>>> If you where right about not basing it on the orbital debris, then we

>>>>>>> should not attempt to be using concepts like seconds, minutes, hours,

>>>>>>> days, weeks, months, years [...]

>>>>>> As you are no doubt aware, the POSIX time_t does not do that.

>>>>> The POSIX time_t still tries to encode it, using some of the 

>>>>> rules that makes of UTC, including SI-seconds. However, the 

>>>>> argument was not about POSIX time_t, but about what "Universal" 

>>>>> in UTC actually means.

>>>> POSIX time_t is explicitly not UTC.

>>> Ah, well, it is explicitly UTC, but not the UTC we'd like.

>>> 

>>> section 3.150 Epoch says - "The time zero hours, zero minutes, zero 

>>> seconds, on January 1, 1970 Coordinated Universal Time (UTC).

>> No. It is *NOT* UTC. It omits leap seconds. It confuses the issue by 

>> using the term UTC when it specifies something that doesn't actually 

>> model UTC, but only an approximation of it, not the actual UTC. It 

>> makes matters worse by specifying a UTC epoch.

>> 

>>> But its described behavior is not *modern* UTC (with Leap Seconds), 

>>> and this is made clearer by section A.4.15 Seconds Since the Epoch -

>> That's rather my point. It is most definitely not UTC.

>> 

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

>> POSIX time_t isn't UTC. Broken down time isn't UTC either.

>> 

>>> "Broken-down POSIX time" is a YY-MM-DD hh:mm:ss representation - a 

>>> *calendar* date-time.

>>> 

>>> POSIX behaves as an *uncompensated-for-Leap-Seconds* Gregorian 

>>> calendar counting scheme.

>> Right, this is *NOT* UTC. That's why I said that it is explicitly 

>> not UTC. It says so in the standard.

> 

> We agree. The standard first explicitly says that it is UTC and then 

> it explicitly says it is *not* UTC.  Why should there be any 

> confusion about this? :-)


It's actually fairly simple.  To be UTC, one needs both the timescale 
origin and the progression rule to conform to TF.460.  

POSIX defines the origin of POSIX time in terms of UTC.  

However, the progression rule is *not* UTC, in that leap seconds are 
not applied (and so all days have exactly the same length, being 86,400 
seconds).  

So, POSIX time is *not* UTC.  One out of two isn't good enough, and the 
fact that broken-down time resembles UTC is irrelevant.

Joe Gwinn