Hacker News Reader

Comment by bombcar | Hacker News Reader

I've always thought that the best way would just have leap seconds every six months, and have it be ± 1 second no matter what - so sometimes you'd go back a second twice in a row, and then go forward a second to get back to correct.

That'd test all the software paths.

View on HN

> That'd test all the software paths.

The daylight savings time bugs I've run into at pretty much every company I've ever worked at would beg to differ.

See also leap year bugs even though that concept has been around even longer than DST.

My favorite is comparing aggregated data across several time zones when DST changes happen.

Shouldn't you just aggregate based on UTC? Leap seconds still cause a problem here but daylight savings shouldn't matter.

People expect e.g. their "daily power consumption" to end at midnight local time. When they zoom in on the daily aggregates, they don't want a spike to suddenly disappear just because it belonged to the next local day and you only stored UTC-day aggregates. Even more so for billing.

The problem is that if the originating system didn't record the time in utc, you've lost the information needed to make the time unambiguous. What's 2022-11-06 01:30 USA/San Francisco in UTC?

How does that solve comparing days with 23 to 25 hours of data when aggregated by hour? Or are you suggesting using days in UTC?

Making time less accurate just for the sake of testing in production doesn't seem great.

From 2035 it's going to be less accurate in exactly the same way. I'd argue bombcar's method is more robust.

I don't know of anything that actually requires UTC to be within 1 second of average rotation-based time; having it within 2 or 3 seconds is extremely unlikely to actually break anything. But we do generally want to have measured time roughly in line with Earth time in the medium to long term.

Today it is within I think +-3 hours of earth time (China being the worst offender), because of timezones and DST. If it ever gets worse than half an hour in a country, they can always change the timezone... or just, like, change businesses' opening hours and stuff.

We have summer and winter time because that turns out to be easier than changing business hours. But I was just talking about UTC really.

How about clocks on Mars? Should these have Earth leap seconds? Time synchronization is already hard enough, complicating it with adjustments based on uneven planetary body movements doesn’t make much sense in a long term.

In the longer term Mars should probably have its own time scale. When we get to further colonization maybe we can use TAI for interplanetary use (but time dilation due to relativity effects is going to be a problem when going to other stars) while still using UTC on Earth.

Better make it every other day rather than every six months.

Henceforth every minute will be "bell curve distribution around 60" seconds long, and each hour will be "bell curve distribution around 60" minutes long.

This variability will provide excellent fuzzing of all time libraries everywhere.

It would test all the software paths in production though. Bad software would still fail and need last minute patches every 6 months.

Reply on news.ycombinator.com