Re: [LEAPSECS] the big artillery
On 2014-10-30 23:57, Clive D.W. Feather wrote: The problem is that some people use UTC to mean TAI plus adjustments to keep it less than a second from UT1 while other people use UTC to mean the basis of legal time here. For the second set, using a new name for a different concept doesn't help. Yes. After leap seconds have been discontinued in (say) 2020, we will certainly need a short name for the time scale disseminated via radio broadcasts and NTP, and that has served as the basis for civil time, both before and after 2020. UTC comes to mind. We may also need a short name for TAI with leap seconds, especially if this is still used after 2020 and disseminated via new channels. Such as UTL for TAI with leaps. I believe that the naming issue can be solved easily once it is clear which time scales have to be distinguished and to be named. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On Oct 31, 2014, at 4:17 AM, Martin Burnicki martin.burni...@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.burni...@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@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs signature.asc Description: Message signed with OpenPGP using GPGMail ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-10-31 11:40 AM, Warner Losh wrote: On Oct 31, 2014, at 4:17 AM, Martin Burnicki martin.burni...@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. Yes. Its primary timescale, sometimes called PTP Time, more properly the PTP Timescale, is a TAI-like counter (uninterrupted incrementing count of seconds). Note its origin, or epoch, is 1969-12-31T23:59:50Z, ten seconds before the POSIX the Epoch (if you take that to mean two years (2 x 365 x 86400) seconds before 1972-01-01T00:00:00Z (UTC), as NTP does). -Brooks 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.burni...@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@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
