On 2017-01-30 01:12 PM, Michael.Deckers. via LEAPSECS wrote:
On 2017-01-30 13:06, Tony Finch wrote:
It's tricky. Bulletin C is pretty clear about when it thinks TAI-UTC
changes:
from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = -
36s
from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -
37s
Pretty clear? Let's try. What does Bulletin C52 say about the
relationship between UTC and TAI when TAI is equal to
2017-01-01T00:00:36.5. Obviously, UTC - TAI at that instant
must be either -36 s or -37 s.
• If it is -36 s, then UTC = TAI + (UTC - TAI) =
2017-01-01T00:00:36.5 - 36 s
= 2017-01-01T00:00:00.5. This is > 2017-01-01, so by Bulletin C52,
UTC - TAI = -37 s, contradiction.
It looks like you intend that "2017-01-01T00:00:36.5" to be a YMDhms
representation of TAI, a pure Gregorian representation with no Leap
Second compensation applied. If so, simply subtracting 36 doesn't result
in a correct UTC YMDhms. Its not a simple mathematical relationship.
That second value, 2017-01-01T00:00:36.5 (TAI), lies within the Leap
Second, so the corresponding UTC would be 2016-12-31T23:59:60.5 (UTC).
To know how produce the correct UTC YMDhms you must have access to the
Leap Second metadata prior to the Leap Second introduction. That's what
Bulletin C is telling us.
• If it is -37 s, then UTC = TAI + (UTC - TAI) =
2017-01-01T00:00:36.5 - 37 s
= 2016-12-31T23:59:59.5. This is < 2017-01-01, so by Bulletin C52,
UTC - TAI = -36 s, contradiction.
Fact is, the statement of Bulletin C52 cannot be true when the
value of
TAI is during a positive leap second, but it doesn't say so.
So yes, pretty tricky.
But I agree its a little tricky. It seems to me this is where the UTC
specifications are scattered over many documents and no one document
makes it clear by itself, and this leaves room for misunderstanding.
If you look at ITU-R Rec 460, ANNEX 3, Dating of events in the vicinity
of a leap-second, its pretty clear the positive Leap Second is
introduced as last the second of the day of the last day of the month
and is labeled 23:59:60. But it doesn't say clearly when the Leap Second
accrues to the TAI-UTC value.
It you look at Bulletin C, and/or other BIPM and IERS products listing
TAI-UTC history, and consider their values carefully in the context of
Rec 460 you can conclude the positive Leap Second occurs at the end of
the day and the Leap Second doesn't accrue to the TAI-UTC value until
immediately after the Leap Second has past, coincident with the midnight
roll-over to the next day.
I concur with Steve Summit's earlier conclusion about the h:m:s sequence
and the corresponding TAI-UTC values - (his example was for the 2015
June/July Leap Second)
Positive leap second:
TAI UTC TAI-UTC
00:00:34.0 23:59:59.0 35
00:00:34.5 23:59:59.5 35
00:00:35.0 23:59:60.0 35
00:00:35.5 23:59:60.5 35
00:00:36.0 00:00:00.0 36
00:00:36.5 00:00:00.5 36
I think this is how most people and implementations interpret it. But
its just not nearly as clear as it ought to be!
Rec 460 doesn't state clearly when the Leap Second accrues to the
TAI-UTC value with respect to a YMDhms representation, although it does
say "2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m
0s of the first day of the following month." Also note TAI-UTC is called
"DTAI" in Rec 460; "E DTAI - The value of the difference TAI – UTC ...".
Bulletin C says "Leap seconds can be introduced in UTC at the end of the
months of December or June". I suppose the phrase "the end of the month"
could be interpreted to mean the same as Rec 460's more complete
explanation of when Leap Seconds are introduced. In addition, "of
December or June" is arguably different from Rec 460's "A positive or
negative leap-second should be the last second of a UTC month, ...."
Also, Rec 460 calls DTAI "TAI-UTC" and this implies TAI-UTC is a
positive value, while Bulletin C gives the values as negative "UTC-TAI".
Cross checking with other TAI-UTC sources is not immediately helpful.
You encounter MJD in IERS
https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat
You encounter NTP seconds in NIST
ftp://utcnist.colorado.edu/pub/leap-seconds.list
If anyone at BIPM, IERS, or ITU-R is listening, it would be really good
to have a single source specification for UTC, or, failing that, at
least bring the documents in line with one another.
-Brooks
Michael Deckers.
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
