3 ms·
I don’t buy that. While positive leap seconds can be mitigated at the OS level, negative leap seconds need to be supported at the application level. A positive
by zarzavat 3y ago
I don’t buy that. While positive leap seconds can be mitigated at the OS level, negative leap seconds need to be supported at the application level.
A positive leap second gives you a discontinuous function from UTC to TAI. But a negative leap second means a function can’t exist at all, because the same timestamp in UTC now corresponds to two moments in time. If someone gives you a timestamp in UTC you can’t know which second it refers to - you would have to switch to giving timestamps in TAI.
- binarycoffee 3y agoWhile this doesn't change the essence of your claim, the problem is not with UTC timestamps but with Unix timestamps. UTC timestamps (HH:MM:SS) are actually unique because the extra second inserted is assigned the numeral 60. Unix timestamps do, however, repeat when a leap second is inserted.
- saltcured 3y agoAnd isn't this problem then the opposite of what is described in the prior post? A timestamp "repeats" to add a second (positive leap second). The subsequent timestamp sequence is delayed relative to its prior offset to TIA. The Google "smear" method works here to slow down the clock rather than repeat values. To drop a second (negative leap second) we have a one second gap in the timestamp sequence. The subsequent timestamp sequence is advanced relative to its prior offset to TIA. This just requires a monotonic jump, as if the computer froze and did not perform any work for one second before resuming with the right clock values.
- binarycoffee 3y agoOh yes, absolutely, GP got it backward and I went along with it...