3 ms·
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 real
by skrebbel 2y ago
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.
- organsnyder 2y ago> 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.
- School-Cotton 2y ago> 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.
- organsnyder 2y agoThe suggestion I was responding to was to basically stop doing this.
- School-Cotton 2y agoI thought it was suggesting exactly the opposite: that we handle this with tzdb updates, not leap seconds.
- skrebbel 2y agoYep! (assuming our grand-grand-grand-grand-etc-children still have something like a tzdb)
- deleted 2y ago[deleted]
- pixl97 2y agoThis 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.