[LEAPSECS] 36 or 37 -- multi-leap

[Tom Van Baak]

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