Hacker News Reader

Comment by bewaretheirs | Hacker News Reader

The drift is sufficiently slow that you can fix it with a "leap hour" when needed -- perhaps once every five thousand years. This could be handled for civil/local time via an adjustment in the timezone definitions (something which happens a few times a year today), leaving the underlying UTC timebase unchanged.

View on HN

Then let's skip the leap hour too: just let UTC and UT1 diverge up to 86400 seconds and compensate that by changing the time zones when needed. Then, when the drift reaches 86400 seconds, the clock times are aligned again. At this point we just need to re-align the dates too, and this can be done by skipping February 29 on a leap year (which should be quite easy to implement in software).

Is that practical? Drift is slow and takes 1 min per century. Let’s say you can live with 10 minutes of drift. That leaves minutes [10-50] which is 4 centuries vs minutes [50-10] where it’s fine which is 2 centuries.

Also, if the problem were time zones, time zones already support non-whole hour shifts, so why not just apply the leap second into all time zones? The reason is that that isn’t what a leap second is. It’s kind of “how much time has elapsed since 1970 midnight” and that number is corrected for with leap seconds. Time zone offsets don’t help you here.

We actually live with about +/- 15 minutes of drift (of local solar noon vs. 12:00 local mean time) over the course of a year. See https://en.wikipedia.org/wiki/Equation_of_time

And timezones one hour wide impose about a +/- 30 minute fixed error (and sometimes larger) on top of that - the difference between local mean time and local civil time.

We have an implicit assumption for definitions of noon and midnight right now. I can't tell if that assumption will be there 1000 years later, but assuming that, UTC and UT1 can't really differ by much more than several hours.

This is the way.

> This could be handled for civil/local time via an adjustment in the timezone definitions (something which happens a few times a year today), leaving the underlying UTC timebase unchanged.

Like I said: it could become a huge coordination problem.

* https://en.wikipedia.org/wiki/Gregorian_calendar#Adoption_by...

* https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale...

it's really just a tzdata update for the vast majority of computer systems. That package updates several times a year. Get the revised rule in there a decade in advance and you're golden.

> it's really just a tzdata update for the vast majority of computer systems.

I don't think you understand how the tzdata works: the tzdata folks only update the contents after the civil authority for a region changes the law.

So first you have to get all the law makers to update what the legal statues say and then you "just" update the computer systems. The latter is the 'easy' part, it's the former that's the coordination problem.

And as someone who was around for the 2005 DST change, I can say that may also be quite the coordination problem. (Though I think code has gotten much better since then.)

Let them handle it in the future when it becomes an issue, in roughly 500 years (that's when the lack of leap seconds will sum up to roughly 30 min). If they still care about having the sun above London at exactly 12 (or whenever it is in ut1) they can handle it.

That's a feature, not a bug. UTC adjustments require world-wide coordination.

Timezone adjustments do not. They are fundamentally a local matter, and just need to be communicated to the tireless maintainers of tzdata, and can happen incrementally any time an area feels local time is too far off solar time.

The main difficulty is convincing Greenwich to not be utc+0 anymore.

Are we actually compensating for continental drift of the area around London already?

My understanding is that clocks in Greenwich are set to utc+1 from the last Sunday of March until the last Sunday of October. (They call it British Summer Time).

Reply on news.ycombinator.com