Posted on 02/05/2005 9:22:39 AM PST by ATOMIC_PUNK
You made it through Y2K, but will you make it through Y2038 (also called Y2.038K)? So why did Y2K go so smoothly? And what is the difference with Y2038?
In Y2K, computers still kept perfect time. The only issue was that software that used only the last two digits of the year had trouble determining that 00 really was greater than 99. It was just a matter of fixing software to use the full year value as it should have to begin with.
But, Y2038 is entirely different. In Y2K, computers still kept perfect time and internally had no problem with the roll-over to year 2000. But not so with Y2038! In Y2038, computers are going to forget how to tell time and for many will roll-back to the year 1970!
This isn't limited to just PCs but many other devices as well. The specs on my wristwatch says that it even stops in 2038!
The problem is that some "intelligent" person years ago used a long signed integer to store the date in the PC as being the number of seconds from midnight January 1st of 1970. The problem is that those 31 bits (31 instead of 32 because of the sign bit) only last until 18 January 2038 at 19:14:07 (for all time zones). At that point the number is too large to fit in a signed integer, overflows, and rolls back.
Why not just add more bits? Well, the problem isn't limited to just software, but many hardware devices also have this limitation.
How do you fix it? Well, you'll have to buy new software for every program you own! And, most all of the computers and hardware will have to be replaced as well!
Can you start fixing it now? The answer is NO. Hardware and software vendors are still developing using this year 2038 limitation.
My conclusion as to why everyone is still developing with this limitation are that 1) it would take quite an effort to start implementing a fix and 2) [probably the more correct reason] by not implementing a fix now, people can make more money. Think about it, not only will people make money on the software and hardware they develop now, but several years from now, they have automatic sales generated by the fact that everyone will be forced to buy new software and hardware. Plus, by waiting to the last minute, not only is there more sales, but they get paid bigger bucks because of the urgency of the problem!
Don't believe me? Well, listen to what Microsoft says: Dr. GUI on the Year 2038 Bug.
However, in that article he incorrectly states that there is currently a work around that solves the problem by using COleDateTime. In a followup article, he explains why that doesn't work: More on the Y2.038K Bug.
Conclusion: Be prepared for Y2038! It is a much much more serious problem than Y2K ever was. Be prepared to spend lots of money and be prepared for all of the problems once predicted for Y2K to actually happen!!
I ran an entire company on an S100 bus CPM machine for several years.
We used WordStar and I wrote the acocunting software myself -- using some Z80 assembler functions.
I had to develop my own memory management modules to devise my own simulated virtual memory.
Ahh, the gold old days. When real programmers managed memory directly.
What's bizarre is that the Macintosh, unlike Unix, uses unsigned 32-bit quantities for dates, but bases its date calculations on January 1, 1904. Can anyone suggest why they might have chosen that as an epoch date?
I'm sure by 2038, Unix, Linux gurus will have rewrote the code.
Actually, in many cases code is not the problem--data is. If you have a database in which dates are stored as YYMMDD (decimal), and in which transactions have to be processed 24/7/365.25, converting the data to a different format is a non-trivial operation. It's not impossible, of course, but ensuring that the data state is kept consistent through the switch can be a challenge.
That said, I really don't see the Y2038 issue as being much of a problem. I would not be surprised if some code uses -1 as a sentinel value, but otherwise I would think most code could migrate dates from an signed long to an unsigned long without any real difficulty. C's typing rules could make a few things a bit irksome, but if code is inspected with some reasonable modicum of care I don't think there should be ably problems.
No kidding. When it all goes to 64 bit (or higher), this whole thing is a moot point.
So, no...the sky isn't falling. It's just frozen Airline toilet waste products that are hitting your roof, people.
It doesn't matter. The world ends in 2010 or 2012 or something. A big meteorite or something. Not to worry.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.