On Thu, Dec 29, 2016 at 4:29 AM, Rob Seaman <[email protected]> wrote: > Warner is staging a spirited defense of POSIX. Such a stalwart champion > deserves a more worthy cause. > > POSIX time_t says they don't exist. Therefore, they don't exist. > > > POSIX, meet physics.
There's nothing that says that DUT1 < 0.9 is sacrosanct. It isn't physics, it's about convention. But we've had this argument many times. > There's millions of lines of code written to POSIX with the mistaken > assumption that they are implementing time correctly. Changing it all, or > even a large part of it, is unlikely to happen. > > > A lot of code could have been changed while the ITU fiddled, e.g., Mac OS X > was launched in 2001. Could have, but didn't. In the interim no contender for best ever time library that solves the leap second problem emerged and was accepted. Of course, MacOS is largely based on legacy code, so in its core libraries little code was added around time. But that's a quibble about the example. > UTC may well be superior to POSIX's notion, but that’s entirely besides the > point. > > > It is the only point. It all depends on the metrics you use to judge it by.... Is time of day more important or interval time more important. > While it might result in a better world if POSIX were able to change, it > isn’t. > > > Placing POSIX in the same “too stupid to fail” basket as the U.S. Electoral > College seems a weak strategy. > > The marketplace has effectively voted with its feet, and change would be too > expensive. > > > But change is what is proposed. That being the case, the simplest change > would be to define a new timescale. Call it “GNU” for "GNU is Not UTC”. Add > one statement to the POSIX standard: > > “After <date> all references to UTC in the POSIX documents, or to > timekeeping generally, will be taken to refer to the GNU time scale, defined > by <document>.” You've obviously never dealt with pervasive standards in coding that date back to the 70's that are nearly impossible to change. Doing that by fiat isn't going to work. > Or simply adopt GPS or TAI, which already have the precise behavior desired. > Commercial devices already exist (and are already widely deployed) that > implement high precision GPS and TAI. Won't work. Been proposed and rejected many times. The basic problem is that things don't work by default. They can't work by default with the current standards, as defined by existing practice. POSIX dropped the ball here in some ways (though to be fair, they were codifying existing practice that dated back to the mid 1970's in UNIX: prior to that epochs changed every couple of years). If there was an easy solution, it would have emerged by now. Trouble is that the details are quite difficult to get right even if you get the standards issues out of the way. And it's for a problem that people sneer at (only a second, why do I care), so there's little support for spending boatloads of money to fix it. The problem is that you never know if the following code has a leap second issue or not. Let's suppose for a minute we redefined time_t to be TAI. Let's further suppose that we can perfectly transmit knowledge about leap seconds to every machine on the planet that's doing time synchronization well enough to care. Let's also suppose the numerous other technical issues are sorted out. How do you know if the following code has issues with leap seconds or not: time_t foo; foo = get_some_time(); foo += 60; do_something_at(foo); Does this code say "do something in 60 seconds" so it will slip 1 second within the minute over a leap second. Or does it say "Do something one minute hence at the same offset within the minute?" For the casual observer, those two statements are the same. but to the computer, they are different. And it isn't something that's easily adaptable to easy detection by the compiler because it's how boatloads of code is currently written. Many of the y2k bugs were caught because the patterns there are easier to automatically scan for. Yet this example illustrates that it can be hard to divine intent. One could imagine having a more complicated structure that could cope with the inherent ambiguity in future times. I can't say "schedule an event exactly 1 year from now" for example without it. I need additional metadata around to know if I want it to happen at the same time of day on the same date or if I want it to happen after than many seconds have elapsed. You can't convert a putative UTC time to TAI time until you are within 6 months of that time (the current announcement schedule) because if you try to compute that time too far in the future, it will change. Absent metadata, you'll have the wrong time. It also means that any interval you compute about a future set of times can change after you've computed it in the light of new data. It's this aspect of the problem that leads me to say it's unsolvable: future UTC is inherently ambiguous because it is tied to a rotating earth and only through observations can we know when to insert a leap second. As an aside, UTC could be made more predictable if a schedule was announced like we do leap days. We can be off by several days because of leap days at any given time, but over the long haul we stay in sync. This change to UTC to give it a predictable schedule at the expense of a little more slop around DUT1 could make many of these issues more tractable, and make it possible to write software that can just work by default. But that's fiercely opposed because of the uncertainty that a DUT1 of 2s or 5s or 10s might cause. We know for sure it messes up some telescopes that have proprietary aiming software that requires that UTC be < 1s so they can acquire the target star for observation before centering it. It's unclear what else breaks, but nobody is eager to find out. This uncertainty will lead to continued inaction as well. We know the day out several thousand years so everybody gets it right, but don't know the time out more than 6 months. Regardless of all the other technology that UTC enables, this is a deep flaw in how UTC is currently realized and is, imho, fundamental to what makes it a hard problem to solve. But we get back to the arguments against this thing "you want to spend how much to retrofit everything so you can get that level of precision?" The "it's only a second" is the enemy of ever getting this right, because there's no perceived value. Some people will try hard to get it right, but most won't care, or even know they have created a problem. Since most people won't fix it, de-facto POSIX runs the show, which has no leap seconds. That's why I said it has de-facto redefined UTC. The impedance mismatch here is growing greater year by year, not diminishing. Having said all that, I totally get why people want UTC to have leap seconds. I get what that enables. I'm suggesting, though, since software is running life more and more, we'll see stop-gap solutions like the smear paper over things until the stop-gaps get too much of a hassle to do and there's a growing call to harmonize the two world views in favor of POSIX. We aren't there yet, I'll freely admit. But the last 16 years I've been involved in the problem, there's been little movement to a real solution to the mismatch and I'm pessimistic that the hard line of UTC can be maintained forever. Warner _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
