Post APpLzdl0KPpBur5O9A by martin@nondeterministic.computer
 (DIR) More posts by martin@nondeterministic.computer
 (DIR) Post #APpLzdl0KPpBur5O9A by martin@nondeterministic.computer
       2022-11-21T11:25:57Z
       
       0 likes, 0 repeats
       
       Leap seconds are being scrapped from 2035! https://www.theguardian.com/world/2022/nov/18/do-not-adjust-your-clock-scientists-call-time-on-the-leap-secondThis is good news for computer systems. In 2012 the leap second crashed lots of websites: https://www.somebits.com/weblog/tech/bad/leap-second-2012.htmlOther leap second problems discussed here: https://queue.acm.org/detail.cfm?id=1967009&doi=10.1145%2F1966989.1967009
       
 (DIR) Post #APpLzeGYR73tUhqaK8 by shironeko@fedi.tesaguri.club
       2022-11-21T11:41:55.390285Z
       
       1 likes, 0 repeats
       
       @martin just use TAI like a sane person and convert to UTC for display when appropriate?
       
 (DIR) Post #APqUirAWIxM7Kl3JEu by martin@nondeterministic.computer
       2022-11-21T13:50:51Z
       
       0 likes, 0 repeats
       
       @shironeko Do you know of any mainstream software that distinguishes between TAI and UTC? AFAIK NTP doesn't. Also, with leap seconds you can't perform the conversion for dates more than a few months in the future, since you don't yet know what leap seconds will be inserted. It would be better to remove the distinction between UTC and TAI entirely
       
 (DIR) Post #APqUirf0Tbk4rJJel6 by shironeko@fedi.tesaguri.club
       2022-11-22T00:54:27.373835Z
       
       0 likes, 1 repeats
       
       @martin I see the problem as an mixup between human interface and the internal representation. For human viewing, a timestamp being a second off for a date in the next year is not that big a deal, and tbh not having leap seconds doesn't really solve the future timestamp issue either because time standard changes all the time (e.g. removing DST). The reason it is very important to distinguish TAI and UTC in code is to tell apart "human interface" code from "internal representation" code. It's the same reason that i18n string handling requires lots of special setup instead of just "replace english string with X language", having the user facing strings and internal strings behave completely differently is vital to keeping mistakes from creeping in.
       
 (DIR) Post #APqVjlHnlGUZKiSC2q by shironeko@fedi.tesaguri.club
       2022-11-22T01:05:50.452790Z
       
       0 likes, 1 repeats
       
       @martin as for "mainstream software" that's the part that trouble me the most, it seem like most people just intentionally choose the way that is the most error prone, I suspect it has something to do with Unix and co (similar to the use of problematic C functions). The best time to solve the issue would have been in the 70s but the second best time is now.also one of the links in the links you shared have this gem, which is amusing > When the software system was replaced in the mid-1980s, the developer (who had not worked on the previous system) did not really understand the difference between UTC and TAI.  I repeatedly — and unsuccessfully — warned both the developer and the US Air Force (the customer) that there would be problems for not doing time conversions correctly.maybe there's an time keeping conspiracy that's keeping people from knowing the right time
       
 (DIR) Post #APqX7EAadeIRWqpkzQ by shironeko@fedi.tesaguri.club
       2022-11-22T01:21:17.620423Z
       
       0 likes, 0 repeats
       
       @martin I think https://skarnet.org/software/ uses TAI internally? they can be found in containers or other places where robustness is favored.