4 ms·
That is absolutely not the only case where an extra second here or there matters. It's just for distributed systems the OTHER ways of dealing with the problems
by nullc 4y ago
That is absolutely not the only case where an extra second here or there matters.
It's just for distributed systems the OTHER ways of dealing with the problems leapseconds create (e.g. using a local monotone clock) aren't available. But even where they are available leapseconds still create issues because they're extremely difficult to test and are often handled somewhat incorrectly.
UTC without leapseconds would in no way be less "for humans". After 4000 years of drift the effect on the solar noon would be about the same as you get driving to the next state over.
- XorNot 4y agoExcept as I noted up thread we've already got "UTC without leap seconds" - it's UNIX epoch time which is defined to ignore leap seconds. Leap seconds are still seconds so even with GPS sync, if all you're doing is tracking 1000ms increments then we have a format already which doesn't have them.
- ncmncm 4y agoExcept everybody is already using UTC, and will not change from UTC to "Unix epoch time" on your say-so. Or to TAI or any other crack-brained system you can think of from your armchair, including all the hardware that cannot be changed without throwing it away and buying new. All we need to do is simply choose not to announce that all the software in the world that (might have) "got leap seconds wrong" but still has to talk to the other half that (might have) "got leap seconds wrong" will be officially broken, this year. Or next year. Etc.
- nullc 4y agoUnless I am misunderstanding what you are writing, you're mistaken about unix time, in practice. In unix time there are 86400 "seconds" per day since the epoch. On days when there is a leapsecond the timestamp of the leapsecond is given out for two (TAI) seconds. A result is that unix time stays in sync with UTC and the difference between them doesn't change. The belief that conventional unix time is somehow leapsecond free is a common source of leapsecond handling bugs. :( It results from misleading standards text which states that it doesn't have leapseconds, which it technically doesn't-- instead leaves the second undefined, which implementations distort to make unix time match UTC. If your goal is to measure accurate durations, synchronize distributed systems, or point telescopes-- unix time will not solve any of your leap second issues.
- XorNot 4y agoThanks for the clarification, but I think my underlying point still stands: ignore leap seconds - invent a time standard without them, which in practice would probably be Unix-time-sans-leap-things, and calibrate off against that. It's plain weird to rewrite the world which doesn't actually care about leap seconds for use-cases which don't work in normal human reaction or processing times. 1000ms is a value only relevant to high precision applications, which are perfectly fine not being tied to a precise date or solar rotation or anything. This feels like a programmers without science training issue: all models are models and you choose the one useful for your purpose. It's particularly galling coming from Meta who are large enough to just do this, write the code, and submit a standard for consideration by the tech-industry.
- ncmncm 4y agoYour "feels" have no influence on any of the firmware in millions of devices that are coded the way they are coded, and cannot be changed, and fail to synchronize with the others that do change in response to a leap second announcement. Those devices do not respond to your sense of fitness. They just fail, and take along everything that has to synchronize with them.