Re:Unix time is bad and needs replacement, not UTC
by ZiiS on Wednesday November 23, 2022 @04:09AM
(#33716831)
Large cloud providers smear time. A day containing a leap second has the normal number of Unixtime "seconds" but each is 1/86400 too long. The inaccuracy this introduces is relevant to such a tiny tiny percentage of use cases; who already have to deal with the extreme complexities of time at this accuracy that everyone wins.
[ Parent
| on HN ]
Re:Unix time is bad and needs replacement, not UTC
by zowie_vd on Wednesday November 23, 2022 @04:19AM
(#33716907)
Large cloud providers are actually exactly the ones who argued that leap seconds should be abolished, so I presume there were enough use cases where this was an issue. I faintly remember one article about the announcement of the voting results where they talked about the issues that smearing could cause but I don't remember exactly what it was, or where I read it.
Re:Unix time is bad and needs replacement, not UTC
by sllabres on Wednesday November 23, 2022 @12:37PM
(#33722170)
Voting running after midnight local time (where leap seconds get inserted) and dependent on sub-seconds, with only five leap seconds since 2000 introduced reads like a really interesting case.
Re:Unix time is bad and needs replacement, not UTC
by Ferret7446 on Wednesday November 23, 2022 @04:54AM
(#33717160)
I find it difficult to believe there are use cases affected by this; given that NTP normally has an error window of some milliseconds, those use cases would never have worked.