Hacker News Reader

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).

View on HN

Exactly, 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

At 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.

Apart from backward compatibility, sounds like a good idea

Reply on news.ycombinator.com