On Fri, Feb 3, 2017 at 4:30 PM, Brooks Harris <[email protected]> wrote: > If its after the Leap Second then your method doesn't work directly; you'd > need to figure it out and make an internal adjustment to the TAI-UTC value a > second *before* its supplied to you, right? See what I mean?
That would be a problem, yes. However, how do you know it is a leap second w/o TAI-UTC changing? You'll need that metadata from elsewhere. To do the leap second correctly, though, you'd need some warning before the leap second that it will, in fact, be a leap second. I'd love to know which spec actually states the offset changes where you say, since it would resolve the ambiguity. Absent a spec, the closest thing is decades of Bulletin C. However, I owe Zefram an apology for being overly grumpy. I thought he was being deliberately obtuse. In reality, his question TAI-UTC at 23:59:59 proved the undoing of what I was advocating. I'm sorry I snapped at him. It was uncalled for. The math works perfectly if you use 60 seconds for the length of the minute before the leap second (the second he had in mind), and 61 after. Not very satisfying, and a hole I had missed. Thinking through what that's the case was helpful. It makes some sense that this would be the case since the leap second isn't part of UTC until it is inserted. Instead of modify the method to cope, I concluded something else. It shows the real crux of my misunderstanding of the nature TAI-UTC. The problem is a confusion between an interval in UTC time, and a difference between two time scales when one of the time scales is using a second label not in the other. A interval in UTC time is well defined and unambiguous. Applying my method to that problem works flawlessly (w/o the suggested 60s kludge above) for computation of intervals within UTC time. Since it works there, one would think it would be a good fit for TAI-UTC since that looks like an interval. However, that's not what TAI-UTC actually is. It isn't an interval, despite being subtraction of two times. They are exactly the same time, so the interval between them is always 0. TAI-UTC is actually an offset between two sets of second labels. One can do that math two ways to get the offset: my way and the conventional way. After reading the standard, which is silent on the issue, neither is inherently right or wrong. It's unspecified in TF.460. However, decades of common usage (Bulletin C) strongly suggests the more conventional way is what's more accepted. Since there's weirdness in what I was advocating, and since it flies in the face of tradition, I'll concede the point. Sorry for the noise. Warner _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
