Comment by creatonez
4 days ago
Any prospect for a leap hour is toast by the time we need it. Over a thousand years of ossification will mean our only option is to not care about aligning clock time to the sun. So it's kinda a joke to even talk about leap hours. I'm shocked they're even mentioning such an idea, they should have declared it as a non-solution.
> our only option is to not care about aligning clock time to the sun
No, an easy option is to simply shift every timezone by an hour and keep UTC intact. A ton of places already do that twice a year for daylight savings.
I never understood why we mess with UTC so much when we already have another widely used mechanism to keep the sun and clocks aligned.
Sure, but political timezones shifted by more than 12 hours 65,000 years in the future seems like the sort of thing that would really screw up our existing code. (I wonder what happens if you put such an entry in tzdata right now? Maybe we should put Null Island at +37:00 or something crazy like +1000:00 to start hardening now)
And maybe we should stop touching political timezones by then anyways.
In less than half a century, we've created 3 different time standards (TAI, GPS, and now UTC) that tick identically and differ only by arbitrary constant offsets (+37, +18 and +0 seconds). If we haven't come up with an elegant solution by then it's likely 65000 years from now most computing power will be spent running time-conversion libraries.
Time zones change all the time, often on amazingly short notice.
Random local government people declare it is to be, and ... as an industry we largely figure it out.
The more responsible governments give amble notice and as an industry we are very very good at that (you not realizing it, is an example).
And good riddance to leap seconds! It was too hard for us to figure out, and they didn't do anything useful for anyone.
1 reply →
Just define new epoch at the turn of a century. Like a "UTD" or "UT2" that begins like 2200/01/01 00:00 that is actually UTC 2199/12/31 11:43:21 or something. Then hardcode the magic TAI number in the headers along the gravity constant and such. Solves the time_t problem too if done every centuries; 2^32 seconds = 136.102208 years. The biggest concern will be that kids at that time will start asking why there was never been UTB and UTA, which our oldest grandkids wouldn't actually know why.
There is a bit of a fine line between caring about the future and not screwing them over, versus just being so arrogant as to think we know now the right thing to do for them.
But given the amount of time it is going to take to accumulate so much as another leap minute's worth of leap time, let alone an hour, I'm pretty confident we're in the "arrogant" branch if we start declaring what they need.
P(nobody cares about UTC anymore anyhow | someone had to solve the problem of incorporating non-terrestrial time which is way harder than leap seconds) would seem to me to approach 100%. You can decide which branch you want to take, but P(things just keep on keeping on without much change from today for the next several thousand years) seems not large enough to start trying to make lots of plans for.
The resolution doesn't actually mention leap hours, just that the delta is allowed to grow up to one hour. What should happen then is to be decided by future generations.
Surely by then we'll have the technology to simply adjust the Earth's rotation so that it conforms to our standards.
A century later we'll finally be able to fix Earth's orbit to make a nice round 360 days per year, 12 months of 30 days, nice and clean, no more complexity or confusion... ah, that'll be the day.
Reminds me of the old "book the meeting on Feb 31" trick to avoid an unwanted meeting.
Heh, I save periodic events as intervals in the database. The upside is it handles weird things like this surprisingly robustly, the downside is that months are months past the start of the year and days are days past the start of the month, yes every thing is zero based. I like it, I feel like I am rebelling against a broken system, but have to make sure I do a conversion to one based months and days for everyone else. Time of day and years are fine, time is already zero based and nobody cares about seeing a year 0.
So the example given Feb-31 is stored as 1 month + 30 days past the start of the year and would trigger right on time march 2nd or 3rd, depending on leap year. In fact I started doing it to handle birthdays on leap day, there is not always a February 29, but there is always a day 29 days after the start of February.
2 replies →
A tzdata update. Boom, done.
they should have mentioned leap day instead. or leap month! if we're going for arbitrary long time period predictions, why stop in some 70k years only?
You'd just shift timezones-- which happens from time to time for political reasons and is well supported.
... of course you're talking about events that would be approximately 4000 years from now!