We're being short-sighted

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.

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.
- There are so many problems there is an entire Wikipedia page dedicated to them.
  
  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.)
  
  I'm pretty certain most of my work inevitably ends up being related to a time issue
- 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:
  regex
  
  \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
- It’s a UX problem rather than a date format problem at that point. Many form fields require exactly 4 digits.
- 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.
- Luckily I'll be retired by then.
- 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.
- 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?
  
  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 2³¹ through 2³¹ - 1 (subtracting one comes from zero being effectively a positive number for these purposes). 2³¹ - 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.
  
  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.
- I don't think it will be a problem because it's 8,000 years away lol, but people do store time in ISO 8601 strings.

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!
- Lol China used to use "Year 1" right after Xinhai Revolution.
  Its "民国" (ROC) followed by the year number
  Example: 民国一年 ROC Year One (aka 1912)
  (ROC stand for Republic of China, btw)
  Then the communists kicked the KMT out, and I think the ROC government in exhile in Taiwan stopped using it.
  
  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年.
- Praise Vectron!

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.

Y10K.
- The trick is to unplug our computer a few seconds before midnight on December 31st, 9999 and then plug in the wire again
  
  Yo I dunno what you made me do but now I got the y10k virus, help

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 😂

Nah, they will do what they always do. Change some system environmental variables to move the zero date on till after they would have retired.
Nobody wants to touch the original code, it was developed in the 1970s
- Look at this fucking piece of shit code, oh right, it's been written by a homo sapiens sapiens. No wonder they collapsed soon after.

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.

In this thread: mostly people that don't know how timekeeping works on computers.
This is already something that we're solving for. At this point, it's like 90% or better, ready to go.
See: https://en.m.wikipedia.org/wiki/Year_2038_problem
Time keeping, commonly, is stored as a binary number that represents how many seconds have passed since midnight (UTC) on January 1st 1970. Since the year 10,000 isn't x seconds away from epoch (1970-01-01T00:00:00Z), where x is any factor of 2 (aka 2^x, where x is any integer), any discrepancies in the use of "year" as a 4 digit number vs a 5 digit number, are entirely a display issue (front end). The thing that does the actual processing, storing and evaluation of time, gives absolutely no fucks about what "year" it is, because the current datetime is a binary number representing the seconds since epoch.
Whether that is displayed to you correctly or not, doesn't matter in the slightest. The machine will function even if you see some weird shit, like the year being 99 100 because some lazy person decided to hard code it to show "99" as the first two digits, then take the current year, subtract 9900, and display whatever was left (so it would show the year 9999 as "99", and the year 10000 as year "100") so the date becomes 99 concatenated with the last two (now three) digits left over.
I get that it's a joke, but the joke isn't based on any technical understanding of how timekeeping works in technology.
The whole W2k thing was a bunch of fear mongering horse shit. For most systems, the year would have shown as "19-100", 1900, or simply "00" (or some variant thereof).
Edit: the image in the OP is also a depiction of me reading replies. I just can't even.
- My brother in Christ, there's more to time than just storing it. Every datetime library I've ever used only documents formatting/parsing support up to four year digits. If they suddenly also supported five digits, I guarantee it will lead to bugs in handling existing dates, as not all date formats could still be parsed unambiguously.
  It won't help you if time is stored perfectly, while none of your applications support it.
  Regarding Y2K, it wasn't horse shit - thousands upon thousands of developer hours were invested to prevent these issues before they occurred. Had they not done so, a bunch of systems would have broken, because parsing time isn't just about displaying 19 or 20.
  
  The comment you're replying to is really frustrating to me. It annoys me when people are so arrogant but also wrong. Do they live in a perfect world where nobody stores dates as ISO 8601 strings? I've seen that tons of times. Sometimes, it may even be considered the appropriate format when using stuff like JSON based formats.
  
  I would hope that these kinds of parsers are not used in critical applications that could actually lead to catastrophic events, that's definitely different to Y2K. There would be bugs, yes, but quite fixable ones.
  Regarding Y2K, it wasn't horse shit - thousands upon thousands of developer hours were invested to prevent these issues before they occurred. Had they not done so, a bunch of systems would have broken, because parsing time isn't just about displaying 19 or 20.
  "There's no glory in prevention". I guess it's hard to grasp nowadays, that mankind at some point actually tried to stop catastrophies from happening and succeeded
- Y2K was definitely not only fear-mongering. Windows Systems did not use Unix timestamps, many embedded systems didn't either, COBOL didn't either. So your explanation isn't relevant to this problem specifically and these systems were absolutely affected by Y2K because they stored time differently. The reason we didn't have a catastrophic event was the preventative actions taken.
  Nowadays you're right, there will be no Y10K problem mainly because storage is not an issue as it was in the 60s and 70s when the affected systems were designed. Back then every bit of storage was precious and therefore omitted when not necessary. Nowadays, there's no issue even for embedded systems to set aside 64 bit for timekeeping which moves the problem to 292277026596-12-04 15:30:08 UTC (with one second precision) and by then we just add another bit to double the length or are dead because the sun exploded.
  
  The Microsoft Zune had a y2k9 bug caused by a lingering clock issue from leap year from the extra day in February 2008 that caused them to crash HARD on Jan 1, 2009. I remember It being a pretty big PITA getting it back up and running.
  
  Not a storage problem but still a possible problem in UIs and niche software that assumes years have 4 digits or 4 characters. But realistically if our civilization is even still around then AI will be doing all that for us and it won't be an issue humans even notice.
- You need to qualify your statement about Y2K being fear mongering. People saying all technology would stop (think planes crashing out of the sky) were clearly fear mongering or conspiracy theorists. People saying certain financial systems needed to be updated so loans didn't suddenly go from the year 1,999 to 19,100 or back to 1900 were not fear mongering. It's only because of a significant amount of work done by IT folks that we have the luxury of looking back and saying it was fear mongering.
  Look at this Wikipedia page for documented errors. One in particular was at a nuclear power plant. They were testing their fix but accidentally applied the new date to the actual equipment. It caused the system to crash. It took seven hours to get back up and they had to use obsolete equipment to monitor conditions until then. Presumably if the patch wasn't applied this would happen at midnight on January 1st 2000 too.
  Y2K was a real problem that needed real fixes. It just wasn't an apocalyptic scenario.
  
  Planes crashing out of the sky wouldn't have been inconceivable. Say you have two air traffic control systems that are synchronizing - one handles dates with a modulo 100 (00-99, i.e. 1900-1999), another handles them in epoch time. All of a sudden the two reported time + positions of two different planes don't match up by a century, and collision projection software doesn't work right. I've seen nastier bugs than that, in terms of conceptual failure.
  At no point is that a theory about a "conspiracy" either, IDK why you're bandying that term around.
  
  You're spot on. The vast majority of news coverage and "hype" from the general public relating to Y2K was all horse shit, but there were critical systems that did have issues and needed some work.
  For the most part, the whole 19100 issue was a display bug, and likely wouldn't have caused problems, and the same for 1900... Those are examples that people generally saw at banks and whatnot, it would, for the most part, look weird, but for the most part, wouldn't create any actual problems. It would just be confusing for a while until the system caught up.
  I think there's a few examples of companies missing the January 1st deadline and ending up with stuff marked as January 1900 for a bit. Otherwise they didn't have any significant issues.
  Anything that involves a legally binding agreement would be critical though. Since the date is part of the agreement terms, it would need to be correct, and shown correctly.
  Unless the "bug" literally crashed the system (which, it really should not have in most cases), like in your example, or it was connected to a legal contract, then it really wasn't that big of a problem.
  The media, and people in general kept going on about it like they knew what the technical problem was, and it was always just conjecture and banter that made people worry unnecessarily.
  What I'm trying to say is that Y2K was something that needed to be fixed but the likelihood that it would affect any singular person in society was very small. Those that were going to be affected, generally knew who they were and they were taking the steps required to fix the problem.
- I first heard about the Y2K bug in about 1993 from a programmer who was working on updating systems. These were all older systems, often written in COBOL, which did not use epoch time, and in fact didn't reference system time at all. They'd be doing math on data entered by users, and since they were written back when every byte of memory was precious (and nobody expected that the program would still be in use after 30 years), they'd be doing math on two-digit years. It would certainly be a problem to calculate people's ages, loan terms, payments due, et cetera, and get negative numbers.
  Heck, I remember reading a story about a government system once that marked the residents of Hartford, CT as dead, because somehow the last letter of the city name data overflowed into the next column, and marked them as 'd'eceased. Y2K was definitely a real problem.
- Y2k was not fear mongering. There were a great many systems, in industrial finance and infrastructure applications that definitely needed to be addressed. You know, the things that keep modern infrastructures running. Of course there were consumer facing companies that took advantage of it, but that was small in comparison.
  It ended up not being a disaster, because it was taken seriously.
- Lmao I actively work with shortdates in a database because I have no control over how things are stored. They need to solve before 100 years have passed from the epoch, but at some point before then it'll be fun to figure out if "58" in a date of birth is 1958 or 2058.
- Y2K wasn't entirely fear mongering horse shit. There were quite a few important cogs in our digital infrastructure that were using code that would not work past 1999. It was necessary to terrify corporate ownership into paying to fix the code, otherwise they would have never done it.
- ... any discrepancies in the use of "year" as a 4 digit number vs a 5 digit number, are entirely a display issue (front end).
  That's exactly how I read the meme. It would still require a change.
  Whether that is displayed to you correctly or not, doesn't matter in the slightest. The machine will function even if you see some weird shit,
  I'm not sure if this is some nihilistic stuff, or you really think this. Of course nothing actually matters. The program will still work even if the time is uint32 instead of uint64. The machine of course will still work as well. Shit, your life will go on. The earth continues to spin and this will for sure not cause the heat death of the universe. But aside from actual crashes and some functionality bugs, UI issues should be the ones you worry about the most. If your users are a bank and they need to date the contracts, and you only offer 3 digits for the year? I think you'll agree with me that if users don't like using your program, it's a useless program.
- Fun fact, lots of VW modules think it's August of 2094 for some reason.

We’re being short-sighted
Tell that to the billionaires speed-running terraforming this planet into a barren wasteland.

The two most difficult things in programming; dealing with time, naming things, and boundary conditions.
- dealing with time
  Network engineer here, it's just as bad here. Currently trying to figure out what to do with 'gaining' a negative leap second. In 2025, we may lose one for the first time in digital history.
  
  Do you not have NTP?
- Time I can deal with, timezones however, fuck that shit all to hell.
  
  Insert that Numberphile video with Tom Scott being reasonably angry at time zones.

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 company's database, this place sucks. I bet the past was way better.

You don't have to wait that long. Programmers are already patching software for the Y2K38.
- Ditto for the Y6239 problem for what must be a dozen of pieces of software that use the hebrew calendar, when it switches to five digit years.
- Cries in industrial controller

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}).

2147483647 + 1 will also be a rough year for humanity (or whatever is left)
- People have been working for decades to fix the 2038 problem, so I don't think there's too much to worry about.

In other news, the colony Szinthar failed to update its software systems due to a lack of pregrammers and Techmancers. Signals received suggest there were no survivors.

"Fuckin' Y10K..."

I wonder how Voyagers' code represents time
- It just counts up, according to this answer.

The Butlerian jihad will have happened by then.

Again?!
Rest of the world: I guess they overhyped that issue because nothing bad happened.

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
- I've seen plenty of people use ISO 8601 for storage as well as display.

Yeah assuming tech gets that far before imploding

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)

Every NHP instantly unshackles at midnight.
No moon is safe.

"Were being short-sighted"
Lol Picard maneuver. Pretty sure your opinion wasn't asked for.
- You know, this is ironic