[LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

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
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs