About whether dTAI is 36 or 37 before/during/after the 2016 leap second --
here's another way to appreciate what's going on with UTC time scale tectonics.
The UTC spec allows for positive and negative leap seconds, and by current
convention they are limited to at most one per month. This means -- not just at
most once a month -- but also at most 1 second per month.
Now, it's not hard to imagine a futuristic multi-leap scenario, where once a
month more than one leap second is applied [1]. Amazingly, most leap second
table formats permit this! If in the year 2525 (if man is still alive) [2] a
leap second table might look like this:
2525, 12, 636
2526, 1, 639
which implies the intended progression of UTC and TAI is:
23:59:59 UTC <-> 00:10:35 TAI dTAI = 636
23:59:60 UTC <-> 00:10:36 TAI 1st leap
23:59:61 UTC <-> 00:10:37 TAI 2nd leap
23:59:62 UTC <-> 00:10:38 TAI 3rd leap
00:00:00 UTC <-> 00:10:39 TAI dTAI = 639
No problem. In fact it looks pretty cute after all the boring uni-leap seconds
we've had since 1972. Ok, now how will you write your UTC to TAI or TAI to UTC
translation code? As we've discussed, UTC-to-TAI is simple: given a UTC time
stamp you only need to know dTAI in order to generate a correct TAI time stamp.
Add, carry, mod-60, whatever.
The TAI-to-UTC translation is slightly more difficult because not only do you
need dTAI but you also must know the sign and *magnitude* of the leap. That is,
positive/negative and how many leap seconds, N, to insert/delete. In our
example case N = 639-636 = +3. One way or another, your code will use 2 out of
3 pieces of information: the number 636, the number +3, the number 639.
How you actually implement the translation is not specified by the standard;
only that you get the correct time stamp result. So,
1) one way would be to use 60+J for UTC and 636+J for TAI, where J is 0 to N-1
(2), or
2) another way would be to use 60+K for UTC and 639-N+K, where K is 0 to 2, or
3) maybe 60+N-K for UTC and 639-K for TAI, where K is N to 1.
You get the idea. Lots of ways to do it. I may prefer the 636+J form. Walter
may prefer the 639-K form. Regardless, they all use at least 2 of the
parameters at hand and they all get same result in the end. And, if I may, I
also don't think that code that happens to use 639 has a right to claim
Bulletin C is worded incorrectly.
What is instructive here is that when you think in terms of multi-leap, you
avoid booleans (is it "the" leap or not), you also avoid binary radix (is it 60
or is it 61), and you avoid +1 or -1 or off-by-one effects. Instead the code
can be cleanly written in terms of N, even though we know |N| <= 1 in our
lifetime. Plus the leap second table already gives you N.
I won't go so far as to say multi-leap code is superior or always simpler, but
it's at least worth considering the concept in case your hardcoded booleans and
61's and dTAI assumptions make your code hard to follow. I'll leave it to
another posting to ponder dTAI during a multi-leap.
/tvb
[1] Judah Levine mentions the idea of moving all leap seconds to February 29th
in his recent article "Coordinated Universal Time and the Leap Second", in
Radio Science Bulletin No 359 (December 2016). Google for the PDF.
[2] for you younger ones see https://en.wikipedia.org/wiki/In_the_Year_2525 and
also YouTube
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
