Are you ready for... 2038? (Y2K38 Bug)

[Rubbereon]

HELP MY MAIN LAPTOP IS 32BIT AND RUNS LINUX

Spoiler

Also XP but XP is pretty much useless now

[close]

Windows XP doesn't have that problem, maybe some apps on it were affected, but as a whole your calendar could last at least 30 hundred years. DOS is even older and it could last up until 2099.

I think for the most part 64bit computers already have the problem solved. Windows should be able to store dates from 1 January 1601 to 14 September 30828. Unix like machines can use dates from 1 January 1970 to 4 December 292277026596 and Macs from 1 January 2001 ±10,000 years.

The article Year 2038 problem most of what could happen. Older  hardware and software that use dates are going to run into problems.

Software will probably have to be changed. I recently came across an old Y2K problem. Excel and Google Sheets now use the 2029 rule to calculate which century 2-figure years belong to. Many of the dates in the source material for pages like this which contain dates from 1860 to 1914 only used 2-digit years so they all had to be checked before I could publish them.

This wikipedia page makes this ordeal confusing. Is Unix or Posix capable of lasting until 292277026596? It says up until version 5.10 linux could only last until 2038 and since version 5.10 it can go up to 2486, so that's for linux specifically and the other value is for posix like FreeBSD (which isn't linux mind you) then?

[PurpleHello98]

I'll probably have to change my OS. Right now I'm using OS X Mavericks, which is 64-bit but still has 32-bit binaries, so it'll probably have some issues. I'll either have to upgrade to OS X Catalina, which can't run 32-bit binaries, or switch to Windows XP. I think some of my iPods won't be able to run (my nanos?) but I believe my iPod classic should be able to run until 2099? So I think I should probably be okay.

Edit: apparently Mavericks works with a date of 2040 according to someone on the MacRumors forum? I think I might have to worry more about the HFS+, but we'll see. I hope I can still use my vintage Macs as long as possible!

[MediocreMetastasis]

⚑ Moderators Note ⚑

Merged into the 2038 topic ^^

I just wanna talk about the Y2K38 bug which is like the Y2K bug. While the Y2K bug existed because they only recorded the last 2 digits of the year rather than the entire date e.g. (only stored 98 instead of 1998 so 2000 would actually be displayed as 1900).  Y2K38 bug is when The date will have an integer overflow on the 19th of January 2038 at 03:14:07 (333... if I done the math correctly) UTC. This is when the number will be too big of a value for the designated bit to store. This can cause two things when running a date dependent application. One the value will roll back to  20:45:52 (666...) UTC 13th December 1901 (not good) or it will throw an integer overflow error (bad!!!!).

I don't see many people talk about this, which is weird, especially since it's a way more harder bug to fix. We can't just change the epoch to 2038 since files with a certain date outside the integer range will break so I'm guessing the only solution is to dedicate more memory to recording the time, 1 bit is pretty much nothing in the modern day but I'm not sure if you need to alter the hardware of all motherboards just so there's more memory for time or you can just update the software for the bios.

Will companies even bother to provide an update to fix this bug? They would make a lot of money if people needed to replace their entire motherboards or even buy a new computer. There are computers that are use in the military and hospitals that still run windows 7, an os that Microsoft does not support anymore, What will happen to them?

Y2K wasn't a big problem as we weren't as dependent on computers and companies weren't as greedy, instead tried to find a solution to the bug and gave it to the public for free.

[Leonia]

The 2038 issue is an interesting one, that has been largely fixed on multiple systems and setups, apparently!

I did only a tiny bit of research but 64 bit operating systems have apparently have swapped to using a signed 64-bit value that gives the maximum year integer the ability to become larger than the estimated age of the entire universe (source).

The C programming language has a lot of unique issues around time_t calls being incompatible to any changes to fix this problem apparently, on one end if you refactor the time *now* then older programs that rely on calling or checking files from before 1970 start to break, which is a problem. If you expand the integer to a 32 or even 64 bit system then you get critical compatibility errors with other programs apparently? I don't know much about this, but I do know that the GNU C library has the ability to support 64-bit time, even on 32 bit systems. (relevant documentation that i have not read but is probably interesting?)

I'm not the most well-read on this subject, though, but the rabbit hole of information and people trying to find solutions for it so far ahead of the deadline is really interesting and cool to read about and look into.

[Dan Q]

You're 100% right: when Y2K hit the public consciousness, it was on the front page of every newspaper, while nerds like me were saying "it's not going to be that big of a deal, planes aren't going to fall out of the skies, the power plants won't shut down, etc... but you ought to be thinking about 2038".

That's not to say that there were no impacts from Y2K-related bugs. One of my favourites to bring up was a major UK supermarket, who had a semi-automated system for stock management in their central warehouse. The pop-culture version of the story goes like this:

The Corned Beef Problem

One day, the warehouse received several pallet-loads of cans of corned beef, fresh off a ship from Argentina. The worker who checked-in the new stock added it to the computer system as the forklift drivers delivered the goods to their bay in the warehouse. One of the things that the computer system asked for was the "best before" date, which the worker entered, something like 31/01/03 - end of January 2003. We don't know whether the worker found it curious that this was the first time they were entering a date on the "other side" of the millenium, but we know they entered it, and we know that the computer system used two-digit years.

The following morning, the computer system ran its daily checks. One check was to look for food that was past its best-before date. And what would you know: one bay of the warehouse was completely full of food that had expired in... 1903! So the computer printed out the morning's orders, issuing instructions to all the forklift drivers to throw away everything in that bay. The computer also put in a fresh order for pallets of corned beef from Argentina, because it noticed that the warehouse had run out.

Fortunately, a staff member noticed the mistake, although not before the goods had been thrown away and fresh ones loaded onto a container ship half-way across the world.

This bug, of course, didn't happen in 2000. It happened in around 1994. Because humans talk about future dates a lot, the Y2K bug hit pretty early (and because tinned food has an exceptionally long shelf-life - always much longer than its BBE dates suggest! - it's unsurprising that it might become one of the first victims of Y2K bugs.

So why aren't people talking about 2038?

The good news is, it's getting fixed with plenty of time. Nerds have long known about the 2038 problem and its solution is clear (even though it's also technically challenging), and most affected systems are already patched or are complicated legacy systems whose owners are at least aware of them.

There'll be some problems, sure, just like the corned beef example above; and they'll probably be subtler, because 8-digit dates won't be affected this time around: this only affects systems that are handling datetimes in a granularity on the scale of seconds. That includes operating systems (which need to know what time it is!), of course, but unless you're running (older) 32-bit operating systems (newer ones have workarounds) you won't even notice.

There are definitely big engineering challenges. The airlines are definitely having a nightmare of a time; ditto the banks - these are companies who are risk-averse and afraid of change, and so many of them continue to use ancient FORTRAN and COBOL systems that are too big/expensive to completely replace, too ancient to patch. But folks running commodity hardware and software - which nowadays powers everything from nuclear power plants to ATMS - will probably be fine.

That's my prediction (and I was right about Y2K): there'll be a few high-profile problems, more-serious than Y2Ks, especially in the years approaching 2038 (and maybe a few on the big day itself), but it won't be catastrophic. The people using big ancient systems know what they're in for and are working on it, and almost everybody else has already got it fixed by their mainstream OS etc.

(Those of us who keep an old OS/2 Warp box somewhere might have problems , but I'm not using my old boxen to keep the lights on; just for fun!)

[ValyceNegative]

This thread is so interesting, thank you @Dan Q and @Leonia , that was very informative!

I lived through the y2k bug craze, though as a 10 years old at the time I wasn't exactly the technical nerd that would dive deep into the actual matters of the bug: instead I enjoyed the stickers, plushies, desktop toys and guides. In some way... I kinda miss that playful side of the craze.
I wonder if it'll come back and if so, what form would the mania take considering how recent "fads" have spread and have been recieved by the public. Some sort of more anthropologic view on the y2k38 bug instead of a purely programming view.

...bottom line I want a y2k38 bug plush 

[OkayRelax]

  Simple.

We make sure this bug doesn't get fixed

DOOOOOOOMMMM

[Dan Q]

I kinda miss that playful side of the craze.
I wonder if it'll come back and if so, what form would the mania take considering how recent "fads" have spread and have been recieved by the public.

Me too. But I suspect we probably won't get the same kind of thing.

Y2K was a huge thing even without the (infinitesimally-unlikely) possibility of computer-fault-related nuclear armageddon. For the first time ever, the entire world was able to appreciate the turn of a millenium, and it came at a time of general optimism: the Cold War seemed done for good, we'd solved the CFC crisis, and the fledgling Internet promised a future of limitless communication and information (in hindsight, of course: the Cold War seems rapidly to be rapidly coming back, we fixed CFCs but the bigger challenge of climate change has only grown since, and the Internet's become for many a place of of censorship and lies).

Plus: we knew that if the Y2K bug wrecked a lot of computers, we'd get by. Most goods and services were purchased with cash. We were very used to being "out and about" and having no way to be contacted anyway. Our lives and livelihoods weren't (quite so) tied to the idea that reliable telecommunications, electricity, and digital banking were essential to our civilisation as we knew it. So what if the phone lines went down for a week in January 2000? We'd get by! But tell a city they're getting no Internet access for a week today and there'll be a riot.

Y2K was a hell of an excuse for a party even without the fun side of "will the Y2K bug get us?" But we weren't so worried about it anyway: what's the worst it could do? Now, a quarter of a century on, the world has changed - perhaps even more than it did in the quarter-century before the millenium. Nuclear-armed countries are sabre-rattling, high-speed always-on communications are part of our culture, and we don't know how to get by without credit cards and contactless payments.

2038 isn't a nice round number (except in binary seconds!), so it doesn't attract mainstream excitement. And the technical risks are bigger and scarier. So no: people won't "party like it's 1999" in 2037/8. It's a different world: sorry!

(Some of you here might be young enough to see in 2100, though! I won't make it that far, but pour one out for me if you get there!)