Warner Losh wrote: >Only for time_t computations. The POSIX expression for time_t, if taken entirely literally, does the same thing. But that's not the only use of a scalar behaving in this way.
> "reducing to a scalar value" unfortunately doesn't map >1-1 onto UTC. Right. The scalar form does not adequately represent UTC. Fully representing a UTC time requires at minimum two parts: an integer identifying the day and a continuous value identifying the time of day. All uses of expressions that treat UTC as a scalar, such as "TAI - UTC" and "UT1 - UTC", need to be interpreted carefully, with the understanding that contextual information is required to perform a complete conversion. > TF.460 says nothing about this. Indeed. It makes some mention of TAI-UTC, but is not explicit about the details of what that means. It does say that it's always integral, but doesn't say when it changes. That is an unfortunate omission. It is the common practice, in IERS documents and elsewhere, not a formal standard, that establishes this usage. One is also guided towards this by its mathematical coherence, which of course is why it became common practice. Your way, doing the arithmetic in the irregular radix implied by the sequence of UTC time labels, leads to more discontinuities. Let's consider (again) the 2016-12-31 leap. One second after the end of the leap second we have (uncontroversially) UTC = 2017-01-01T00:00:01.0, TAI = 2017-01-01T00:00:38.0, TAI-UTC = 37 s. In the middle of the leap second, 1.5 s earlier, we have UTC = 2016-12-31T23:59:60.5 and TAI = 2017-01-01T00:00:36.5. For you to derive TAI-UTC = 37 s as you do essentially requires that we interpret that TAI label as if it were a UTC label and ask how many seconds there are between these two UTC labels. That's what using the irregular radix amounts to. OK, that gets 37 s. Now let's go back another 1.5 s, to a point one second before the start of the leap second, and continue working that way. We have UTC = 2016-12-31T23:59:59.0, TAI = 2017-01-01T00:00:35.0. The difference between these two timestamps, taking account of the irregular radix, is *still* 37 s, made up of 2 s from 23:59:59.0 to 00:00:00.0 plus 35 s from 00:00:00.0 to 00:00:35.0. So in your system the discontinuity in TAI-UTC is not, as you stated, at the beginning of the leap second. Working backwards, we find that TAI-UTC actually changed at 2016-12-31T23:59:24.0 UTC, which is 2017-01-01T00:00:00.0 TAI. At that instant we have (still using the irregular radix) a 37 s difference in the time labels. Half a second earlier we have UTC = 2016-12-31T23:59:23.5 and TAI = 2016-12-31T23:59:59.5, with an uncontroversial difference of 36 s. Essentially, your system perceives UTC as a continuous scalar, and perceives a discontinuity in *TAI*, where it jumps from 2016-12-31T23:59:59.9 to 2017-01-01T00:00:00.0. TAI omits a second's worth of time labels supplied by the irregular radix, 2016-12-31T23:59:60.0 to 2016-12-31T23:59:60.9. A negative leap is worse, because TAI takes on labels that don't exist in the irregular radix. How do you account for that? If we permit the out-of-radix :59, with its apparent numerical value, then we find that the notional TAI scalar repeats a second's worth of values, with out-of-radix notation being used to distinguish the two instances of those scalar values. Any computation that produces this TAI scalar in its pure form cannot be used to unambiguously decode a TAI time. Essentially, your irregular-radix system has the same problems for which you deride the regular-radix system. The difference between the systems is in to which time scale they attribute the discontinuities that arise in TAI-UTC. Performing the computations using the regular radix attributes them to UTC. Using the irregular radix attributes the discontinuities quite unfairly to TAI. There's also a theoretical problem when TAI-UTC gets big enough to span the time between two leap seconds. Theoretical because UTC breaks down in other ways before we can actually reach that. But if it were to occur, your irregular-radix arithmetic would see additional complexity. To get the results that you stated, with TAI-UTC changing at the beginning of the leap second, by using the irregular radix for the arithmetic, actually requires that you use the irregular radix selectively. You used it for the conversion of times lying within the leap second, but not for other times. That's not a coherent system. I think what you *actually* did in your head was more coherent than that, but wasn't the use of the irregular radix that you claimed. What you did, and halfway described, was to treat 2016-12-31T23:59:60.5 as 2017-01-01T00:00:(-1).5. You treated the leap second as being prepended to 2017-01-01 rather than postpended to 2016-12-31. In that scheme, the notional UTC scalar, when computed as I have described using the regular radix, does undergo discontinuity at the beginning of the leap second, with the leap second duplicating the scalar values of the preceding second. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
