[LEAPSECS] the big artillery

[Warner Losh]

On Nov 3, 2014, at 1:37 PM, Brooks Harris <brooks at edlmax.com> wrote:

> 
> 
> On 2014-11-03 03:04 PM, Warner Losh wrote:
>> On Nov 3, 2014, at 12:53 PM, Brooks Harris <brooks at edlmax.com>
>>  wrote:
>> 
>> 
>>> On 2014-11-03 02:19 PM, Warner Losh wrote:
>>> 
>>>> On Nov 3, 2014, at 11:11 AM, Brooks Harris <brooks at edlmax.com>
>>>> 
>>>>  wrote:
>>>> 
>>>> 
>>>>> CAUTION about the PTP Epoch. Its not "just nitpicking”.
>>>>> 
>>>>> 
>>>> ...
>>>> 
>>>> 
>>>>> We've been advised by PTP experts that A) yes, its confusing, and B) most implementations use a integral-second interpretation, as in Table B.1. I understand the "escape clause" they use to justify this is the "(POSIX) algorithms" phrase in Note 1 of 7.2.2 Epoch. By "(POSIX) algorithms" they mean "gmtime()" and (strict) POSIX "ticks" at 1Hz, so, integral seconds. In any event its really the only interpretation that yields a manageable, practical, implementation that is consistent with TAI and UTC, NTP, and common-use of POSIX.
>>>>> 
>>>>> 
>>>> A few years ago, I had to produce TAI-like data from a measurement system. We defined the value as “seconds since 1970” but the technical definition was "number of SI seconds since 1 Jan 1972 00:00:00 UTC + 10 + #seconds-in-1970&71” to avoid the ambiguity. Given that our chief time scientist suggested this, and they were quite involved in PTP…
>>>> 
>>> I assume you mean "number of SI seconds since 1 Jan 1972 00:00:00 UTC + 10 - #seconds-in-1970&71” ? And the "#seconds-in-1970&71” is (2 * 365 * 86400), right? That would be coincident with the PTP Epoch as interpreted above, that is, "seconds since 1970 (TAI)”.
>>> 
>> TAI is ahead of UTC, so you have to add in the leap seconds to UTC to get TAI. At 1 jan 1972 00:00:00 UTC this offset was 10s, exactly. To bias the date back to 1970, you have to add in 2 * 365 * 86400, to give a value of 63072010 for 1 jan 1972 00:00:00 UTC. I don’t think you want to subtract it, since that leads to an epoch of 31 DEC 1973 00:00:00 due to the leap day in 1972, right?
> 
> OH, well, which way round are we calculating? 1972-01-01T00:00:00Z (UTC) + 10 = 1972-01-01 00:00:00 (TAI) - (2 * 365 * 86400) = 1970-01-01 00:00:00 (TAI) = 1969-12-31T23:59:50Z (proleptic UTC). RIght?
> 
> (Of course its just these knids of miscommunications that lead to the great confusions and debate over UTC and "civil time"...)

I think you have it backwards. If we count the number of SI seconds since 1972, then to rebase that count to an epoch of 1970 rather than 1972 we have to add in those two years.

Numbers we want at start of:

1970 = 0
1972 = 2 * 365 * 86400 + 10 = 63072010
1980 = 10 * 365 * 86400 + 2 * 86400 + 19 = 315532819

Numbers of SI seconds since the start of 1972:
1972 = 0
1980 = 8 * 365 * 86400 + 2 * 86400 + 9 = 252460809

so to make a count since 1972 into a count since 1970, given these numbers, we have to add in 63072010 to the second set. This gives us a pseudo-count of seconds since 1970 which is related to the current unix time_t value by adding in the number of leap-seconds valid for that number, which is what the PTP timescale should give us if you read the standards documents right. And it does so w/o the ambiguity of UTC’s rubber seconds and tiny leaps during the 1970-1972 period.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20141103/c5d10900/attachment.pgp>