Y10K.
The trick is to unplug our computer a few seconds before midnight on December 31st, 9999 and then plug in the wire again
Programmers in 292,271,023,045 after uint64_t isn’t enough for the unix timestamp anymore:
Programmers dealing with the timezones of asymmetric period binary and trinary star systems once we go interstellar 💀
Fucking forgot to use a time dilation safe type for storing my time variables
Please no.
Don’t worry, we’ll be extinct soon, hopefully. Maybe even before int32_t runs out. Unfortunately not soon enough to stop the humans impact on earth before the worst damage is done.
well there have been mass extinctions before, the most notable maybe oxygenation catastrophe , mainly caused by photosynthetic life.
And it represented a major breakthrough for life on Earth, so i doubt that this one is an irreparable crisis.
I’ll let you in on a secret.
Humanity and the animals that we like will get through just fine.
Humans in general and the vast majority of biodiversity will be fucked if it ever happens.
I firmly believe it won’t. Too many good people in the world doing far more than the shitty ones.
Except the shitty ones have more money and political power.
There might be a new calendar year system by then. Probably some galactic dictator who says that the beginning of their rule is now Year Zero.
Year Zero of the Glorious Zorg Empire!
Praise Vectron!
deleted by creator
and I think the ROC government in exhile in Taiwan stopped using it.
Actually it is still used. It’s everywhere in legal documents, government documents and stuff. Though people more commonly say 2024 instead of 民國113年.
I don’t think 10000 year is a problem. There is a real “year 2038 problem” that affects system storing unix time in signed int32, but it’s mostly solved already. The next problem will be in year 33000 or something like that.
It’s going to be significantly more than the year 33000 before we run out of 64-bit epoch timestamps.
The max value for signed 64-but epoch values is more than 292 billion years away, or 20 times the age of the universe itself.
So yeah, we’re basically solid forever with 64-bit
33,000 would come from other programs that store the year as a 16-bit signed int. Year 32,768, to be precise.
I’ve been curious about that myself. On one hand, it still seems far away. On the other hand, it’s a bit over 13 years away now and I have gear actively in use that’s older than that today.
Is there an ELI5?
Unix computers store time in seconds that have passed since january first 1970. one there have been too many seconds since 1970, it starts breaking. ‘signed’ is a way to store negative numbers in binary. the basics of it are: when the leftmost bit is a 1, it’s a negative number (and then you do some other things to the rest of the number so that it acts like a negative number) so when there have been 09999999 seconds since 1970, if there’s one more second it’ll be 10000000, which a computer sees as -9999999.
A common method of storing dates is the number of seconds since midnight on Jan 1, 1970 (which was somewhat arbitrarily chosen).
A 32-bit signed integer means it can store numbers between 231 through 231 - 1 (subtracting one comes from zero being effectively a positive number for these purposes). 231 - 1 seconds added to Jan 1, 1970 gets you to Jan 19, 2038.
The solution is to jump to 64-bit integers, but as with Y2K, there’s a lot of old systems that need to be updated to 64-bit integers (and no, they don’t necessarily have to have 64-bit CPUs to make that work). For the most part, this has been done already. That would put the date out to 292,277,026,596 CE. Which is orders of magnitude past the time for the sun to turn into a red giant.
Maybe it’s not LI5, but I certainly enjoy your explanation for including several important facts and context. I respect your skill and knowledge, dear internet stranger.
There are so many problems there is an entire Wikipedia page dedicated to them.
I’m pretty certain most of my work inevitably ends up being related to a time issue
Yes, there are random systems using every kind of smart or brain-dead option out there.
But the 2038 problem impacts the previous standard, and the current one will take ages to fail. (No, it’s not 33000, unless you are using some variant of the standard that counts nanoseconds instead of seconds. Those usually have more bits nowadays, but some odd older systems do it on the same 64 bits from the standard.)
It’s a UX problem rather than a date format problem at that point. Many form fields require exactly 4 digits.
Well, I looked at a Year 10000 problem less than 2 hours ago. We’re parsing logs to extract the timestamp and for that, we’re using a regex which starts with:
\d{4}-\d{2}-\d{2}So, we assume there to be 4 digits for the year, always. Can’t use it, if you live in the year 10000 and beyond, nor in the year 999 and before.
Just start over at year 0000 AT (after ten thousand)
The ISO time standard will certainly need to be redone
Do you think so? Surely, it’s able to handle dates before the year 999 correctly, so I’d also expect it to handle years beyond 10000. The
\d{4}is just our bodged assumption, because well, I have actually never seen a log line with a year that wasn’t 4 digits…Kinda?
Each date and time value has a fixed number of digits that must be padded with leading zeros.
To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.[21] An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[22] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.[23]
Oh wow, I really expected the standard to just say that however many digits you need are fine, because you know, maths. But I guess, this simplifies handling all kinds of edge cases in the roughly 7975 years we’ve still got.
it’s mostly solved already
I wished I believe this. Or I guess I agree that it is solved in most software but there is lots of commonly used software where it isn’t. One broken bit of software can fairly easily take down a whole site or OS.
Try to create an event in 2040 in your favourite calendar. There is a decent chance it isn’t supported. I would say most calendar servers support it, but the frontends often don’t or vice-versa.
Luckily I’ll be retired by then.
What about the year TREE(3)?
Ugh, I definitely don’t have the bandwidth to support anything beyond the year graham’s number.
“How many years is that?”
“At least THIS many.” (holds up 4 Knuth’s arrow notations fingers)
Awww shit, time to rewatch my favourite Jike Mudge movie starring Lon Rivingston; Space Office (9999).
Haha, I can’t believe this guy has the job of manually changing all the dates on the companies database, this place sucks. I bet the past was way better.
In 9999, this meme will be problematic because it assumes the entire galaxy conforms to an Earth-based calendar system.
Well the USA is on Earth so obviously the earth calendar is the default.
Still set by London 😂
Good news! We’ll be exctinct long before this happens. One less thing to worry about!
Seems hyperbolic to assume we will be extinct by 9999.
Sure we’re heading for a climate crisis, but I don’t think all humans will be dead; Just the poorest.
That has forever been the fallacy.
The poor won’t die in the apocalypse leaving only the rich behind. The poor will die, and the rich will be faced with the harsh reality that they needed an army of poor working under them to sustain themselves, leading them to all die within the generation.
That’s true until it isn’t. Automation is on its way. Marching ever onward.
The factory I work in built a new building this year that employs 1/4 of the workers as the next newest one and does 2.5x the output.
You still need loaders, drivers, retailers to get anything to the customer. A lot of rich ski and holiday towns can’t staff the stores and Cafe’s, because the employees can’t afford to pay rent in the same towns, so they face a similar issue…
Amazon is already testing robotic loaders, self driving trucks are already in development, and vending machines retail everything in Japan.
Maybe, but there are still a lot of invisible people involved to get the food all the way to your table. And small suppliers cannot afford to switch their whole operation to robots.
Yeah so they go out of business lol
The Butlerian jihadn will have happened by then.
We’re being short-sighted
Tell that to the billionaires speed-running terraforming this planet into a barren wasteland.
I wonder how Voyagers’ code represents time
It just counts up, according to this answer.
oh just start at 0000 again, signate that as 10,000. Files didn’t start until like 1979 anyways, and there can’t be many left, and even if it is a problem, now you have 2000 years to not worry about it.
“Were being short-sighted”
Lol Picard maneuver. Pretty sure your opinion wasn’t asked for.
Actual programmers wondering why this joke doesn’t mention 65535…
Actual programmers wondering how you’ve never seen anyone use ISO 8601 strings as storage.
Years
YYYY
±YYYYY
ISO 8601 prescribes, as a minimum, a four-digit year [YYYY] to avoid the year 2000 problem. It therefore represents years from 0000 to 9999, year 0000 being equal to 1 BC and all others AD, similar to astronomical year numbering. However, years before 1583 (the first full year following the introduction of the Gregorian calendar) are not automatically allowed by the standard. Instead, the standard states that “values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange”.[20]
To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.[21] An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[22] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.[23]
If you’re being handed a string 2022424-12-19T14:44:39Z, and told it’s ISO-8601, you should be able to figure it out. Really, a decent parser should be able to recognize that on its own (just use {4,} instead of {4} in regex). It does mean that non-hyphenated YYYYMMDD shouldn’t be used (I typically never see them encoded that way) - but even if you did, you’d just do (\d{4,})(\d{2})(\d(2}).
I get your point, but in the same way that people “shouldn’t” have been using two digits for year storage, there are certainly many parsers of ISO 8601 that don’t match the spec. In 8,000 years I don’t think this will be a problem though lol. I don’t think we can really perceive what technology might be like that far in the future. But, hypothetically, is year 10,000 was in a few days and this was year 9,999 I would suspect we’d see at least some problems come January.
As an example, YAML 1.2 changed Boolean representation to only be case insensitive in 2009, but in 2022 people still complain about the 1.1 version. (Caveat: I don’t know if this person actually ran into a “real” problem or only a hypothetical one.)
I mean, that’s exactly what programmers in the '70s thought. That there would be no way in hell that their crap code would still be in use going onto 2000.
Thing is, copy/paste is always going to be easier than writing new code and that’s only going to get worse as chat bots start coding for us.
30 years is very different than 8000 lol.
More of a front end issue actually, almost all time is just stored as the number of seconds since 00:00:00 Jan 1 1970.
And it’s represented as a 64 bits value, which is over 500 billions years.
64 bits value
… About that… https://en.wikipedia.org/wiki/Year_2038_problem
That’s the 32 bit timestamp
We’ve still got time to fix it, and the next release of Debian will likely have a time-64 complete userland. I don’t know the status of other “bedrock” distributions, but I expect that for all Linux (and BSD) systems that don’t have to support a proprietary time-32 program, everything will be time-64 with nearly a decade to spare.
Yup. Gentoo people are working on it as well. This is only a problem on 32-bit Linux too, right?
I think it affects amd64 / x64 because they originally used a 32-bit time_t for compatibility with x86 to make multiarch easier.
I don’t believe it affects arm64.
This is for a 32bits encoded epoch time, which will run out in 2038.
Epoch time on 64 bits will see the sun swallow Earth before it runs out.
I’ve seen plenty of people use ISO 8601 for storage as well as display.
