On Mon, Feb 6, 2017 at 6:39 AM, Zefram <zef...@fysh.org> wrote: > Warner Losh wrote: >>So either there's some weird math that lets one subtract two numbers >>that are different and get 0 as the answer, or the delta has to change >>at the start. > > To the extent that they're different, the things being subtracted are > not numbers. The expression "TAI - UTC" is shorthand for something more > complicated than a numeric subtraction, which will nevertheless produce > a numeric result. The linear reduction of a timestamp that Clive and > I have separately described is sufficiently numerical to admit of a > straightforward subtraction, and the linear reductions of N:23:59:60 and > (N+1):00:00:00 are duly the same.
Saying that the two numbers are the same is improper. Or rather, it depends on which time scale you are looking at them in if they are improper. In UTC they are clearly not the same, but different second labels. UTC can express this non-sameness. TAI can't do that, so you have to reduce the improper time to a proper one before you can compare them. There's two ways to look at it: convert them both to TAI or convert them both to UTC. So, if you look at the two times in TAI land, you have to do that folding of seconds that's implicit in the linearization formula. If you do that folding of seconds, then the 60 in the irregular radix takes care of the difference in the first second since you've folded its value to the value of the first second of the next day. That means you have to say the difference starts after the leap second. However, if you look at the two times in UTC land and compute a delta in UTA land, then you find the interval between N:23:59:60 and N+1:00:00:00 you wind up with 1 second. That leads to the conclusion that the difference starts at the beginning of the leap second. The whole discussion about when the difference starts can be boiled down to that. What's the proper way to look at it? Depends on how you do the math to do the conversion to when you use the new offset. > An analogy: suppose we do a bit of arithmetic in hexadecimal. We can > all agree that 0x5a0 - 0x5a0 = 0x0. Suppose that while keeping the > hexadecimal radix we additionally use the digit "g", with value sixteen. > Now we find that 0x5a0 - 0x59g = 0x0. The difference is zero, yet the > numbers appear different. What's going on? Well, the numbers per se > are the same: 0x5a0 = 0x59g is a single numerical value. The things > that are different are the digit sequences "5a0" and "59g", which under > the convention being used here are two different ways of expressing that > single number. The digit sequences are not themselves numbers. I think now you're getting confused about irregular radix. If we were to do that with hex, the number 0x59g would be a non-normalized number that normalizes to 5a0 because hexadecimal is a regular radix. You can't normalize N:23:59:60 to N+1:00:00:00 because in UTC they are two different second labels. Put another way: it's indisputable that if I have one event at N:23:59:60.1 and a second event at N+1:00:00:00.6, they happened 1.5s apart. Also, I'll note that bulletin C says from 0h, which is a time expressed to only one significant digit. They chose to not use the unambiguous 00:00:00 opting for the less precise 0h. If you make the second folding argument via time linearization, you map both the leap second and the first second of the next day to the same value. Which one of those is 0h? I think the final answer is: It's ambiguous and I was wrong to insist that there's one true way to recon it. Warner _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs