News for hackers. Stuff that matters.
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.
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.
Re:Unix time is bad and needs replacement, not UTC by goodpoint on Wednesday November 23, 2022 @05:05AM (#33717233)
Wrong. The smearing cumulates during a day...