On Nov 3, 2014, at 1:37 PM, Brooks Harris <[email protected]> wrote:
> > > On 2014-11-03 03:04 PM, Warner Losh wrote: >> On Nov 3, 2014, at 12:53 PM, Brooks Harris <[email protected]> >> wrote: >> >> >>> On 2014-11-03 02:19 PM, Warner Losh wrote: >>> >>>> On Nov 3, 2014, at 11:11 AM, Brooks Harris <[email protected]> >>>> >>>> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
