3 ms·
I'd argue any system that's affected by leap seconds should be using TAI, and accepting that showing users the time (or accepting user input) is going to requir
by aragilar 2y ago
I'd argue any system that's affected by leap seconds should be using TAI, and accepting that showing users the time (or accepting user input) is going to require an up-to-date table of conversions (it's not like a leap second is any bigger of a deal than the various changes to timezones).
- mavhc 2y agoExactly, we already store and show dates and times differently due to time zones, just add seconds to that alteration too. we have tzdb, add lsdb for leap second database and we can work out the difference for any time in the past, or near future
- eyelidlessness 2y agoAt that point, why not just move leap seconds entirely into local time as part of the time zone offset? Track each time zone’s initial, current, and (inevitable for at least some locales) final leap second offset. Include it directly in the numeric expression of the offset. Freeze UTC at the initial offset, update the relevant specs to provide for this, and call it effectively “done”, where “done” is that leap seconds are an entirely human-facing, local-jurisdiction-governed concern, entirely derived from monotonically incrementing base time.
- mavhc 2y agoApart from backward compatibility, sounds like a good idea