[LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-01 10:12 AM, Steve Summit wrote:
> I wrote:
>> For every let's-look-at-the-arithmetic argument that suggests we
>> should use the "new" offset during the leap second, I can come up
>> with one which suggests the opposite.  (Basically it depends on
>> whether you come at the leap second "from below" or "from above".
>> I'll send the longwinded details in a separate message, if anyone
>> actually cares.)
> So here's that 2016-12-31 leap second progression again:
>
> 	row	TAI     	UTC     	TAI-UTC
> 	1    	00:00:35	23:59:59	36
> 	2    	00:00:36	23:59:60	36? 37?
> 	3    	00:00:37	00:00:00	37
>
> Looking at row 1, everything makes sense.  We can compute
> TAI - UTC = TAI-UTC; we can compute TAI - TAI-UTC = UTC; we can
> compute UTC + TAI-UTC = TAI.  Everything lines up; everything
> is consistent; TAI-UTC is clearly 36.  And similarly for row 3,
> where TAI-UTC is just as clearly 37.
>
> But, not surprisingly, row 2 is where everything gets crazy.
> :36 is clearly one more than :35, and :60 is clearly one more
> than :59, so all the math works out consistently if we keep using
> a TAI-UTC offset of 36.  For example, since 00:00:35 - 23:59:59 = 36,
> we would have to agree that (00:00:35 + 1) - (23:59:59 + 1) = 36,
> meaning that 00:00:36 - 23:59:60 = 36.  This is what I meant by
> "coming at it from below".
>
> But if we come at it from above, starting on row 3, we just as
> easily get the other answer.  :36 is clearly one less than :37;
> :60 is (reasonably) clearly one less than :00.  So if 00:00:37 -
> 00:00:00 is 37, then subtracting one from both operands gives us
> 00:00:36 - 23:59:59 which must also be 37.  QEND.
I'm sure we all know to be very careful about zero-based counts v.s. 
one-based counts and how easy it is to make off by one errors. There's a 
bunch of factors in these TAI-UTC value lookups and application to 
YMDhms conversion. When you come at it from top or bottom like that it 
can be confusing for sure.
> If we try to convert TAI to UTC on row 2, I absolutely agree with
> Warner that 00:00:36 - 36 looks like it ought to equal 00:00:00,
> and that 00:00:36 - 37 has a much more likely chance of working
> out to 23:59:60.  This is a persuasive, very nearly compelling
> argument.
Yes, its convenient that way, from one point of view. But I really don't 
think that's what the specs say (see other email), and the manner the 
data is presented in the Leap Second tables is consistent with TAI-UTC 
updating after the Leap Second. If you need, or want, it the other way 
you can arrange that if you choose, no?. In Warner's case he'd have to 
adjust the incoming TAI-UTC data to suit his needs in some way or other, 
I think, right? Any implementation will probably need to make some sort 
of adjustment in this respect, depending on internal data structures and 
methods employed.

> But when I come up at it from below, I can just as
> persuasively and almost-compellingly convince myself that the
> offset should be 36.
>
> Part of the problem, as Zefram has pointed out, is that when we
> attempt to compute 00:00:36 minus anything, we're subtracting a
> relative time from an absolute TAI time, which gives us another
> absolute TAI time, *not* a UTC time.  So the method is already
> suspect.
Yes, there is no uninterrupted incrementing numbering that represents 
UTC. Indeed, that's the whole point, isn't it? UTC = TAI - TAI-UTC, 
right? This will repeat the UTC seconds value:

2016-2017 Leap Second
TAI seconds TAI-UTC UTC seconds
1861920034 - 36    = 1861919998
1861920035 - 36    = 1861919999
1861920036 - 36    = 1861920000
1861920037 - 37    = 1861920000
1861920038 - 37    = 1861920001

That's what it does. That's what its *intended* to do. That's the 
information by which the Leap Second is *encoded* into the UTC YMDhms 
representation. 1861920036 - 36  = 1861920000 is the Leap Second, and 
that's where the YMDhms sequence must read 2016-12-31 23:59:60 by 
whatever means necessary.

It is of course not a consistent mathematical relationship; its a 
purposely applied discontinuity to adjust the UTC YMDhms label. The UTC 
YMDhms is an *encoding* of the TAI seconds value. That's what UTC is, 
right?

>
> The leapsecond-handling code I've been writing recently is based
> around a table that can tell me, for a given (UTC) timestamp,
> what the day length and TAI offset are for the UTC day containing
> that timestamp.  Given that architecture, I pretty much have to
> have the TAI offset for the last second of a leapsecond day
> matching the other 86400 seconds on that day.  When, belatedly,
> I attempted to write a TAI-to-UTC conversion function last week,
> I had problems with the leap second; I had to introduce a
> kludgier and less-obvious special case than I expected to.  I now
> realize that Warner is right: if TAI-UTC were one greater during
> that second, the code would be a little cleaner.  But (in my case,
> at least) there would be a substantial, and considerably greater,
> amount of code elsewhere that would end up substantially messier.
>
> I'm beginning to suspect that the reason the Standards don't
> clearly tell us what TAI-UTC is during a leap second is that all
> the people who wrote those Standards went down the very same
> roads we're going down now, and couldn't decide on a good answer,
> either.
As I said, I really think the standards *are* clear on this.

-Brooks


> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>