Hacker News new | past | comments | ask | show | jobs | submit login

Right now, converting a count of seconds (slightly fictitious UTC seconds, that is) since the epoch to a human-readable time is simple modular arithmetic. Any beginner in a programming language can do it.

If this conversion required knowing the number of leap seconds that have gone by, then simply displaying a human-readable time, or doing things at a fixed human-centric time of day like midnight UTC, would require a library almost as difficult to maintain and update as tzdata. In practice, some people wouldn't bother, and timestamps would gradually become ambiguous.

People on HN keep proposing tracking leap seconds the same way as time zones, and aren't thinking through the implications of having another tzdata-like layer that will display all your times wrong if you don't keep it updated. (Yes, GPS needs that layer. Most people do not program the GPS system.)

(also, just stop adding leap seconds, ffs, then this idea would work fine and nothing real would suffer)




Couldn't you have the best of both worlds by just augmenting timestamps to be <UTC seconds, count of leap seconds elapsed> ?

That way you still get the easy modular arithmetic, but an application that expects monotonic time still sees it (simply locally sum the two fields).


Cool. That actually seems like a good idea, unlike the "leap seconds are just time zones, what's the problem" one. Now you're just left with the practical problem of changing the representation of timestamps.

(It's not even that the Unix timestamp representation was short-sighted. Unix was invented before leap seconds.)




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: