The Year 2038 Problem

[AnglRdr]

Originally Posted by Salamander

The question is more "What legacy systems will still be in place and will we know to fix them, or be able to fix them?".

I am fairly confident our AS400 system at work will still be in use. Flaming POS that it is.

[Troberg]

Granted, the benefits of more bits is linear to the number of bits

And, of course, what I meant was:

"Granted, the benefits of more bits is not linear to the number of bits"

Just a typo, in case someone wondered if I'd suddenly gone insane.

The question is more "What legacy systems will still be in place and will we know to fix them, or be able to fix them?".

Legacy software, probably, but this is not a software problem.

Legacy hardware, not likely. 30 year old hardware is a lot. Anyway, this hardware problem can be compensated for in software. Just interpret the dates from 1901 (which it will roll over to) as 2038 dates, and so on. Most likely, this will be done in the BIOS or OS. Remember, software can store dates in a more flexible manner, so it just needs to correctly understand the system clock, then it can store it whatever way it wants.

At any rate, I look forward to coming out of retirement in 2037 in order to charge obscene amounts of money for my expert knowledge of the then-archaic Windows XP OS.

You assume that they'll manage to make a followup to Vista that people will actually use?

[Sebbenth]

Originally Posted by Troberg

The 2038 problem is a hardware problem, specific to PC hardware.

Nope. It's a poor basic class problem in a lot of systems applications.

The average life span of a PC is less than five years. I think they can fix the problem in almost six generations.

In this case, it will pretty literaly mean that they will have to migrate entire applications from 32-bit time format to 64-bit time format. In quite a few cases it will be a lot harder than you think.

[Troberg]

In this case, it will pretty literaly mean that they will have to migrate entire applications from 32-bit time format to 64-bit time format. In quite a few cases it will be a lot harder than you think.

Most applications already use a time format that handles the problem just fine. For instance, the MS world uses a 64 bit floating point format which, iirc, works nicely up to the year 6000 (it can go further, but, at least the tools I've used put a limit there as a reasonability check). Why? Because you already have to be able to store dates beyond 2038 in lots of applications.

The 2038 problem only affects how the system clock is translated to a date. As we know when it will roll over, we can adjust accordingly. If the clock tells us 1902, we can easily add logic to tell that it's actually 2039. The system clock is read through API calls in the OS, so it's a single point where the code has to be changed to handle this.

Or, in other words: The system clock counts seconds since 1 Jan 1901. Higher up, in the OS or in the BIOS, this second count is translated to a date. Since we know that 1901 is unlikely to happen again, we just start over with a new baseline in 2038 when the counter rolls over to 0. When, say, Excel, wants to calculate the what date it will be in 10000 days, it asks the OS for the current date, which in turn asks the BIOS. When Excel gets an answer, it is in a form that handles dates after 2038, then it adds 10000 days to that, and stores the result, also in a form that understands dates after 2038.

The Y2k problem (allegedly) affected software that did not use a full four digit year. In practice, few systems actually cared or just experienced some minor sorting issues. To solve this, software was modified to use four digits. The Y2k38 problem is not in software, software already handles it. Lots of stuff, like loans, insurances and so on already needs to handle those dates, so the software development tools already handle it. It only affect one single point in the computer: how the system clock is translated to a date, and all calls to get the current date go through the same code, so only one place needs to be fixed.

[FullMetal]

Originally Posted by Salamander

The question is more "What legacy systems will still be in place and will we know to fix them, or be able to fix them?". At any rate, I look forward to coming out of retirement in 2037 in order to charge obscene amounts of money for my expert knowledge of the then-archaic Windows XP OS.

The fact that people have known about this 2038 issue since long before y2k, (yes the argument can be made that y2k was known long before as well, and nothing was fixed until panic time) the truth is people are resolving this issue. a lot of infrastructure around here has already resolved the issue in those systems. in fact I personally know some programmers who were brought in to look at old cobol code to fix the y2k issue on a system that wasn't even affected by the problem. but they put in place an upgrade path over 38 years to prevent the 2038 issue. as they felt their time shouldn't be wasted, and in 38 years they hoped to be retired...

[Sebbenth]

Originally Posted by FullMetal

The fact that people have known about this 2038 issue since long before y2k, (yes the argument can be made that y2k was known long before as well, and nothing was fixed until panic time) the truth is people are resolving this issue. a lot of infrastructure around here has already resolved the issue in those systems. in fact I personally know some programmers who were brought in to look at old cobol code to fix the y2k issue on a system that wasn't even affected by the problem. but they put in place an upgrade path over 38 years to prevent the 2038 issue. as they felt their time shouldn't be wasted, and in 38 years they hoped to be retired...

OK, here goes the joke:

One Cobol programmer was so afraid of Y2K program that he froze himself to be thawed somewhere in mid-2000's. So, he finally wakes up, finds himself in a totally futuristic room with a bunch of bald guys clad in metallic clothes. So, he goes:

- So, what happened? Did the world end?
- No, just your unit malfunctioned and you didn't defreeze properly. Millenia passed. We've moved way beyond your primitive ways of 20th century. We mastered interstellar travel, found the source of everlasting youth and the source of perpetual energy. Perhaps, you will find it hard to fit in here.
- So why wake me now?
- You see, year 10 000 is approaching and your resume says you know Cobol...

That is really good with the year 10.000.

Truth is, that I am amazed how viral news spreads in this new era of the internet.

The 2038 problem is real (as far as some programmer friends of mine told me), but it is impossible in computer age not to solve a problem. I am not sure what will be 2 years from now mainstream on the internet, who knows 20 years from now?

[Errata]

It's the year 292,277,026,596 problem that keeps me up at night. All these programmers will just switch to 64 bit time to fix the 2038, but they're just passing the buck to their great great great great * 10 billion grandchildren who will have to deal with the 64 bit time overflowing.

[Errata]

Originally Posted by Mad Jay

I'd be surprised if by 2038 there would be any computers left with 32 bit OS. Windows comes up with a new OS what every 2 years now? THe various versions of Linux already have 64 bit versions coming out. Almost all the popular programming languages have 64 bit compilers available. THe 2038 problem might simply require a recompilation of code (I know easier said than done, but still much simpler than actually changing code). In case of interpreted or JIT compiled languages like Java, nothing will be required because the VM is going to take care of it.

It's not that simple. It's depends on what language and software you use, but regardless of what kind of processors you're using, the code can still use particular sizes of data. Even on 32 bit processors you can specify a 64 bit data type if you like, and even on 64 bit processors, you can specify a 32 bit data type. Sure if people are all using an appropriate "time" data type, then theoretically they can just change a header file and recompile. But it isn't always the case that people do it right the first time. There are often built in assumptions that break when you change something like that. Java is no exception, although it's perhaps more likely that people stuck to using an appropriate time class with no assumptions about it's size. Assuming not everyone in the world has been appropriately cautious, and it would be a miracle if they were, then there will still be code that needs to be fixed up in order to keep working.

And when you get into databases, you have to specify how large you want each field to be, regardless of what hardware you're running it on. Cobol is at heart built around database transactions, and it will have information on fields coded in that aren't as simple to correct as just recompiling or running the program on hardware with larger registers.

Originally Posted by AnglRdr

That's when all my spam is dated (not the eating kind, the email kind).

Maybe the world's financial systems will fail because of all the free cash gifts I'm supposed to collect on. And also, Viagra.

Originally Posted by ButterscotchCat

Wow, wierd, mine too.

That's because spammers post-date email messages to be the first you see when you open your Inbox.
If they put 2038 their emails will be the first... forever!