Hi Warner, > But consider TAI and UTC when they were equal, for the sake of > argument. I know they never were, but if we look at what the first one > would look like:
That's a nice, clear example. Thanks. > 23:59:58 23:59:58 0 > 23:59:59 23:59:59 0 > 00:00:00 23:59:60 1 > (since how can it be 0 if they are different?) Ah, the offset can be 0 *because* they are different. In fact, the offset *must* be 0. You see, there's no need for *both* the :60 *and* the 1 offset at the same time. Each of them on their own are capable of indicating a one second difference from normal: - A :60 by its unique value tells you there is a now an offset of +1 second in the time scale. - And dTAI being 1 tells you there is now an offset of +1 in the time scale. You don't need *both* of them. When you're in a leap second, the extra-normal value of the :SS itself tells you an offset. And when you're not in a leap second that information carries over to dTAI to tell you the offset. Their *sum* at any instant is the difference between the time scales. > 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. > > It's understanding what the weird math is that I'm having trouble with > for people that say it is after the leap second that the delta > changes. Well, yes, it is sort of weird math. It's operations on time stamps, not integer counts of seconds. Look at it this way: - In decimal arithmetic you have 10 symbols, so you carry when you pass 9. If you wrap from 9 to 0 and do not carry you've lost count. - In seconds arithmetic you have 60 symbols, so you carry when you pass 59. If you wrap from 59 to 00 and do not carry you've lost count. Further, UTC is not just regular time stamps. Leap seconds are clever. They invent a new symbol, called "60". This symbol, by its very existence, holds a new count without actually carrying. It allows you to postpone the carry until you are ready to wrap to 00. Once you wrap, though, something else needs to keep track of that extra count or you'll lose count. And that something is dTAI. So this means the time scales physically diverge at the beginning of the negative or positive leap second, but the integer value of dTAI doesn't increment until you're finished with the time stamp(s) that have excess-60 in them; that is, at the moment you roll over to :00. Remember, the pseudo math you're trying to solve is something like this: TAI = UTC + (TAI-UTC) It's not being done with integers, in decimal or in hex; it's not even being done in mixed-radix 24:60:60 format. Instead it's being done with an optional extra symbol. So the "equation" is always true. It's just that once in a while, during a positive leap second, the value of the "UTC" in the equation (via use of an extra symbol) is 1 greater than usual. To keep the equation true, the value of "TAI-UTC" remains the same while this happens. It's only when the time stamp rolls over to :00, that the extra 1 moves over from the "UTC" part to the "TAI-UTC" part of the equation. /tvb ----- Original Message ----- From: "Warner Losh" <[email protected]> To: "Leap Second Discussion List" <[email protected]> Sent: Friday, February 03, 2017 1:30 PM Subject: Re: [LEAPSECS] BBC radio Crowd Science > On Wed, Feb 1, 2017 at 11:14 PM, Warner Losh <[email protected]> wrote: >> On Wed, Feb 1, 2017 at 10:37 PM, Zefram <[email protected]> wrote: >>> Warner Losh wrote: >>>>If you are going to willfully misunderstand, then I'm done being patient. >>> >>> I am not willfully misunderstanding. I have tried to understand >>> what you're doing, and I've been unable to find a system that works >>> consistently, uses the labelling of leap seconds on which we are agreed, >>> and yields TAI-UTC changing at the start of a positive leap second. >>> Please enlighten me. If you were to supply the couple of worked examples >>> that I have suggested, I believe that would shed much light on your >>> system. >> >> I've already done exactly that. I'll see if I have time tomorrow to >> write it up again using TeX or something that's easier to format and >> explain with than ASCII text. Based on Tom's description of my method, >> I think he may misunderstand it too. It's as consistent as the >> calendar system we have today. > > I'm doing a longer write up, but work got crazy... > > But consider TAI and UTC when they were equal, for the sake of > argument. I know they never were, but if we look at what the first one > would look like: > > TAI UTC delta > 23:59:58 23:59:58 0 > 23:59:59 23:59:59 0 > 00:00:00 23:59:60 1 > (since how can it be 0 if they are different?) > 00:00:01 00:00:00 1 > > 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. > > It's understanding what the weird math is that I'm having trouble with > for people that say it is after the leap second that the delta > changes. > > Warner > _______________________________________________ > LEAPSECS mailing list > [email protected] > https://pairlist6.pair.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
