Hacker News Reader

>So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second.

Shifting the prime meridian 400km seems like it'd have some unintended consequences akin to the Y2K problem. Its physical location is used as a reference point in some coordinate systems, ECEF for example.

You don't need to move the prime meridian, you just need countries to update their individual time zone offsets from UTC, which is already a well-supported path that happens all the time. If we abolish leap seconds, countries would just wait until solar noon drifted ~30 minutes (which would take centuries), then just do a TZ offset update. Nothing could be simpler.

Are you suggesting a solution akin to UTC-4:00 is now UTC-4:00:01?

That sounds like a headache of epic proportions when contrasted with the alternative of a leap seconds.

No, they're suggesting a solution akin to Eastern Kazakhstan was on UTC+6:00:00 one day, and on UTC+5:00:00 the next day.

This actually happened last March[0] and I'm not aware of anyone outside Kazakhstan being inconvenienced by it at all. tzdb updates happen several times a year and everything keeps working fine.

0: https://data.iana.org/time-zones/tzdb-2024a/NEWS

No, I'm saying that e.g. Central Europe Time keeps being defined as "UTC+1" for the next few centuries until solar noon has drifted about 30 minutes away from civil noon, then CET's definition changes to be UTC+0 or UTC+0:30. This is a time zone update of the sort which happens constantly (e.g. in 2017, Chile changed its TZ offset, Haiti started using DST and Mongolia stopped using DST. A TZ offset change to account for clock drift would be exactly the same)

> NEEDS sub-second precision

To be clear, for decades, we've not sought sub-second precision. We've sought precision of a second. Maybe we should seek more-- the big problem with leap seconds is that they've been rare enough to not be tested completely well, but common enough to provoke problems.

> And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now.

Then everything in the world that displays time is going to need a software update when you're going to do this, or it will show time off by 15 minutes.

I do think it could be sane to let UTC's offset to drift up to +3.0 to address this temporary trend of a "fast Earth". Of course, that's going to make leap seconds rare for awhile, and it will come back and bite us when the recently-untested event of a positive leap second happens again.

> Then everything in the world that displays time is going to need a software update

Have you seen how often tzdata updates are published? There tend to be multiple each year. Stuff already should be auto updating this.

(Python, but good reference: https://github.com/python/tzdata/releases )

Yes, stuff should be, but a 15 minute adjustment within a zone suddenly is going to screw a lot of devices. Not everything that consumes UTC is internet-connected.

Heck, every existing radio-derived clock that presents time to users would be obsolete (lots of GPS, WWV/DCF watches, etc).

A lot of them have TZ-related breakage, but they usually let you set a manual hour offset or consume a daylight flag.

I think you are underestimating how long the scales are here. It could take 1000 years to be off by 15 minutes. By this time every electronic device that exists today will be either gone or in a museum.

I know it's a long time. But it's probably more like 200-250 years or so to be off by half of 15 minutes (which presumably is when you'd do a 15 minute step). And it might be a lot less than this.

In any case, I think frequent, well-tested procedures are better than an exceptional procedure on the order of decades or centuries.

The point is that it is a frequent, well-tested procedure, because governments decide they want to be in a different time zone (or have different DST rules) all the time.

Yes, but as stated-- 15 minute offset changes is a very infrequent procedure, and not every device consumes new tz data.

> > > but a 15 minute adjustment within a zone suddenly is going to screw a lot of devices"

There's a whole lot of devices where all you get is a manual hour offset and a daylight flag for outdated tz data.

> That doesn't feel like something that NEEDS sub-second precision.

It does not need to be sub-second, but sub-seconds add up over time.

The Julian calendar wasn't that far off, but it was cumulative, so to fix things it took a ten day jump:

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

It is considered easier to have a few small(er) semi-regular jumps than suddenly having to making giant, sudden, one-off jump in the future.

We make small semi-regular changes to timezones all the time. DST switches, governments arbitrarily deciding that their country is going yo be in a different timezone (at a 2 day notice), or move the DST switch day by 2 weeks, etc etc. This is a solved problem and it happens all the time. The systems and datastructures that can deal with this (eg tzdata and the process & people behind it) are already in place.

> This is a solved problem and it happens all the time.

UTC changing does not happen all the time: what the 'all the time' thing is a display/UI offeset against UTC. Time itself is not changed in those situations, but would be with a 'UTC jump'.

The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. And if something as common and regular as that gets fumbled I have little hope for pulling off a one-off jump of UTC.

It is coördinating the universal part that I would imagine to be the difficult part.

Then just keep UTC when it is? (ie allow its prime meridian to shift away from Greenwich) Adjust all the timezones by half an hour in a few millennia. It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide.

Really, this is a non-problem.

> It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide.

I'd rather build gradual adjustments into our systems so that they have to be resilient to this sort of thing. Sure, leaving it up to our distant descendants is enticing, but then they're going to have a Y2K-sized problem to fix. I'd rather leave a legacy of systems that were designed to be resilient.

> then they're going to have a Y2K-sized problem to fix.

No they aren't. tzdb updates happen several times a year already, and you don't notice.

The suggestion I was responding to was to basically stop doing this.

I thought it was suggesting exactly the opposite: that we handle this with tzdb updates, not leap seconds.

Yep!

(assuming our grand-grand-grand-grand-etc-children still have something like a tzdb)

This really doesn't solve anything either. Attempting to treat time as something that ticks towards the future at a consistent rate relative to all observers is already broken. The Earths rotation is slowing down over geologic time. Even on short orders things like earthquakes can change rate of rotation of the planet. Start putting stuff on spaceships and different planets and you start seeing how wibbily wobbily time really is.

Just like we have to focus on making application secure, we need to ensure our applications don't shit their pants when applications change time in unexpected ways.

The universal part is alread coordinated, the problem is that it keeps adding and removing seconds with no regularity and little advance notice.

It feels like you missed the main point. Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.

> Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.

TZ changes are a display delta against UTC. The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. If something as common as February 29 is fumbled, what are the odds of pulling a one-off event?

And as someone who was a sysadmin when the US changed its TZ rules many moons ago, the sudden rule change was anything but straight-forward given the fairly static nature that they had been for the long history of software development that had occurred until that point: a lot of software is US-developed, and there was little/zero consideration to updating rules. (Though I think that event caused a lot of developers to be more understanding.)

In 400 years we can define new 30 minutes shifted timezones and in 400 - 500 years governments can slowly change their official timezones (maybe at summer/winter time they shift 30 minutes instead of 60). It does not feel like a big issue.

The point is we don't need to change universal time. Thousands of years from now, when solar time drifts away from UTC enough for a particular country to care, that country can change its time zone. There doesn't need to be any global coordination and the process will be gradual enough that nobody will notice.

The EU already fails to agree on dropping DST (and adjusting time zones in the process), because member states will be affected differently, and neighboring countries that should really be in different time zones benefit from being in the same zone. I doubt they could agree on shifting their time zones, because invariably some countries would get the short stick.

I keep repeating this point but for some reason people keep ignoring it. Countries do not have to agree to change time zone. They can each change it whenever they want.

The point is they will not want to change their time zone to a different one from their neighbors if they are in the same zone, because that has economic downsides. And the neighboring country will not want to change along because winter mornings will be too dark or whatever. It’s exactly the issue that currently prevents dropping DST in the EU, although a majority would prefer not changing clocks twice a year.

I think that getting all of Europe to change time zone offsets by 30 minutes once every 400 years is within our power.

> I think that getting all of Europe to change time zone offsets by 30 minutes once every 400 years is within our power.

It took about 400 years for all countries to finally go from Julian to Gregorian. :)

> So let's just wait until there's 15 minutes of error - a couple of millenia from now.

This might already happen in 200-300 years, because the delta increases quadratically: https://www.ucolick.org/~sla/leapsecs/deltat.html

I wouldn't even suggest a solution. Let the people thousands of years in the future figure it out. Working out solutions now is like asking people from the time of Jesus what we should do about the clock for a worldwide computerized network.

> So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km

Perhaps a couple of millenia down the road, we have the technology to speed up/down the rotation of the Earth in order to keep it synced with UTC.

We already have that system, and it's called TAI. You are free to use TAI instead of UTC in your computing projects, and don't have to try to change the definition of UTC.

> You are free to use TAI instead of UTC in your computing projects, and don't have to try to change the definition of UTC.

Not if you want to interoperate with basically any other system that uses time.

Which is a very good reason to abolish the leap second in UTC to make it the same as TAI time. We can then make a new standard that includes the leap seconds and add them to that (which computers will only ever deal with when they format datetime).

Leap seconds are absolutely part of the local datetime conversion functionality of time and not part of the counting functionality. Unix time should never have been different from TAI time in the first place but somewhere along the line some idiot made the absolute undeniable blunder of putting the seconds offset of the suns position relative to earth in the counter of seconds rather than putting it in function that formats the local datetime.

Anyway here we are. It’s totally fair that UTC includes leap seconds but unfortunately they passed on UTC as is into the unixtime seconds counter which makes no sense since computers don’t print UTC datetime directly anyway, they have a special date() formatting functions that could easily and problem free add seconds as needed.

So what’s the solution? Well telling everyone to suddenly adopt TAI is difficult. But we could just abolish leap seconds from UTC effectively migrating everyone without them realising it. Now I know that sounds odd. After all this blunder wasn’t done by the UTC creators, it was the Unix guys that fucked up here. UTC is literally meant to track the sun after all. But still it’s the easiest fix and we can always create a new UTC, UTC_leap_seconds, that we can use in our datetime printing functions if we want. Abolishing leap seconds from UTC and thus Unixtime will make the world run more smoothly. It’s also been planned as we speak so you don’t need to do anything but wait! :)

I don’t disagree!

> Which is a very good reason to abolish the leap second in UTC to make it the same as TAI time. We can then make a new standard that includes the leap seconds and add them to that (which computers will only ever deal with when they format datetime).

But, once again: that already exists!

Sure but sometimes we have to do things twice because of a fuck up.

Because changing the definition will make old-definition systems magically interoperable with new-definition systems?

It’s not changing any definition, it’s ceasing to add any new leap seconds to UTC. Which is what the BIPM is planning to do anyways!

I'm trying. I don't even know if rust or c++ have tai yet

This would be a feature of the underlying platform and nothing to do with the programming language.

"move the UTC prime meridian"

We'd have two prime meridians. One for time and another for longitude. (Not a deal breaker but we'd have to plan for it.)

We have many prime meridians for longitude. The location of 0° on Earth is not the same in every datum.

We also moved the traditional prime meridian by a hundred meters back in 1974 with the adoption of the IERS Reference Meridian.

Said another way, the prime meridian adjusted by (at max deviation) 0.1km 50 years ago and hasn't been changed since.*

*Though on a small scale, tectonic movements fuzz the idea of "location" in general.

I vote to correct the clocks once a century. Then it'd be infrequent enough to have a big celebration rather than being annoying.

> Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST.

Any DST aware system I've checked handles this as a timezone change rather than changing the underlying time, expressed in UTC. Even for locations where DST's onset removes an hour rather than adding one.