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
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
