3 ms·

That is a different problem. You usually work with timestamps and then convert the time to local time only when displaying it or doing calculations that depend

That is a different problem. You usually work with timestamps and then convert the time to local time only when displaying it or doing calculations that depend on the particular timezone. So it's less of a problem, since at lower levels you don't have the concept of timezone (you may never have it, for example on embedded devices). But if UTC shifts, it's another story. You assume the UTC (or UNIX) time to be a monotonic counter, and usually it's used this way, for example you compare two timestamps to know what definitively happened before another thing. Surely you don't take into account leap seconds... this is the problem. Leap seconds wouldn't be that much of an issue if the time is only increased, you have one more second, it's the higher level implementation that has the concept of time to (maybe) deal with it. But they become an issue if they can take behind the UTC clock since it can generate all sort of strange bugs. It's even a worse solution to make the duration of a second in a day longer or shorted, because you preserve the counter value, but you no longer can rely on the fact of 1 seconds being 1000ms long! By the way the concept of leap second is nonsense to me. What is the purpose? If the purpose is to keep in sync the time with the rotation of the earth, nobody will ever notice an error of a couple of seconds, or even minutes. It makes more sense to take the current definition of a second, and then wait till the error is noticeable to an human being (let's say an error of 15 minutes, that would take centuries and we will probably far gone from the planet) and adjust it by shifting all the timezone for that amount of time.

elfchief 4y ago
Actually, UTC -is- continuous. Even with leap seconds. At no point does UTC go backwards, at no point does a second happen twice, and at no point does a second change in length -- your 'extra' second happens as 23:59:60; when there's a negative leap second, the last second of the day is 23:59:58. UTC is not expressed or defined as an offset from some time in the past. The real problem for computing is when UTC is converted to unix epoch time, which is defined as an offset from the past, and by definition has exactly 86400 seconds in a day, every day, so some provision has to be made for those extra (or missing) seconds. And -that- is where the problem happens. But it's not UTC that's mucking around with the definition of time, it's the standard representation of time that's used in modern computing that causes the problems. That being said, UTC is still probably to blame for most of the problems, because it effectively requires knowledge of more than just a timestamp to understand when something actually happened. And that extra knowledge (the map of when leap seconds have happened before) changes often and irregularly. Epoch time could totally be redefined to include leap seconds, and that would solve lots of problems, but there's no practical way to distribute that updated leap seconds table to every system that would possibly need it...
a9h74j 4y ago
> and adjust it by shifting all the timezone for that amount of time Does this follow as a question?: Shift the timezones geographically, or in terms of how they all define [true monotonic] to local-time translation?

elfchief 4y ago

Actually, UTC -is- continuous. Even with leap seconds. At no point does UTC go backwards, at no point does a second happen twice, and at no point does a second change in length -- your 'extra' second happens as 23:59:60; when there's a negative leap second, the last second of the day is 23:59:58. UTC is not expressed or defined as an offset from some time in the past. The real problem for computing is when UTC is converted to unix epoch time, which is defined as an offset from the past, and by definition has exactly 86400 seconds in a day, every day, so some provision has to be made for those extra (or missing) seconds. And -that- is where the problem happens. But it's not UTC that's mucking around with the definition of time, it's the standard representation of time that's used in modern computing that causes the problems. That being said, UTC is still probably to blame for most of the problems, because it effectively requires knowledge of more than just a timestamp to understand when something actually happened. And that extra knowledge (the map of when leap seconds have happened before) changes often and irregularly. Epoch time could totally be redefined to include leap seconds, and that would solve lots of problems, but there's no practical way to distribute that updated leap seconds table to every system that would possibly need it...

a9h74j 4y ago

> and adjust it by shifting all the timezone for that amount of time Does this follow as a question?: Shift the timezones geographically, or in terms of how they all define [true monotonic] to local-time translation?