[LEAPSECS] the big artillery

[Warner Losh]

On Oct 31, 2014, at 4:17 AM, Martin Burnicki <martin.burnicki at meinberg.de> wrote:

> Magnus Danielson wrote:
>> On 10/31/2014 02:49 AM, Sanjeev Gupta wrote:
>>> Give it a new name, please.  Independent of what the "fundamental
>>> unit" is.
>> 
>> TAI and UTC already exists, but the use of TAI has been actively
>> discouraged.
> 
> Huuh?
> 
> Just "recently" PTP/IEEE1588 has been specified to use TAI timestamps by default, and provide a UTC offset as parameter.
> 
> As far as I can see it's easy to derive "legacy" UTC from TAI unambiguously if you know the current offset, and if you have a leap second table available this also works for timestamps from the past, at least after 1970. So what could be the reason *not* to use TAI?

BIPM (or their successors, I can never keep all the reorgs straight), the owners of TAI, have discouraged it. The reasons are that while it is similar to UTC, it differs in some technical ways. TAI and UTC have a fixed offset relationship, it is true. However, UTC is computed in real time (with several varieties to choose from if you care about the nano-seconds), but TAI is a retrospective timescale that’s not computed until after the fact. I get the feeling that the BIPM want TAI to be their baby, free from “production” concerns that UTC  has to deal with

IEEE isn’t part of BIPM, so they are free to do what they want, and they make a contrary recommendation. But if you look closely, they aren’t recommending using TAI, as BIPM defines it, they are using the TAI second labeling for this real-time realized timescale. So this is a real-time realization of a timescale whose seconds are numbered like TAI rather than like UTC. It isn’t a TAI timestamp, since technically those have to be compute after the fact from the raw data rather than done in real time. But it is a timestamp using the TAI conventions for labeling of seconds. The difference is subtle, and for PTP makes no difference at all, but does exist.

>> The trouble is that those that wants a TAI-like time-scale
>> sometimes needs to comply to UTC needs, and for a number of reasons they
>> have difficulty in using it, so they want to make UTC a TAI-timescale.
> 
> The naming of a possible future UTC-like time scale without leap seconds is a different topic, though, and I fully agree with Harlan's and Sanjeev's recent postings.

Rules change all the time as do the details (UTC pre 1972 is significantly different than post 1972 for everything except the tracking UT1 attribute), sometimes the name changes, other times no. Sometimes the change matters to a lot of people, other times not so many (like the black body correction introduced in the 1990’s). But that’s a different set of posts, eh?

Warner

> Martin
> -- 
> Martin Burnicki
> 
> Senior Software Engineer
> 
> MEINBERG Funkuhren GmbH & Co. KG
> Email: martin.burnicki at meinberg.de
> Phone: +49 (0)5281 9309-14
> Fax: +49 (0)5281 9309-30
> 
> Lange Wand 9, 31812 Bad Pyrmont, Germany
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung
> Web: http://www.meinberg.de
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

-------------- 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/20141031/d5fd8c64/attachment.pgp>