Y2K and Linux

By: Lou Grinzo
Friday, January 1, 1999 12:00:00 PM EST
URL: http://www.linuxplanet.com/linuxplanet/reports/726/1/

In the Beginning...

The root cause of the Y2K problem was economics, pure and simple. Back in the bad old days of computing, computer storage, both RAM and disk space, were unimaginably expensive by today's standards. (Talk to enough long-time programmers, and you'll hear stories about mainframe programs designed to run in just a few thousand, or even hundred, bytes of memory.) Many programmers therefore had little choice but to conserve every byte possible, and one common trick was to store just part of the year for dates, so 1960 was shortened to 60. Programs that used this trick "knew" to add 1900 to the year, so they worked properly, and everyone was happy.

Of course, things changed, as they always do in this industry; storage got cheaper, and the need to resort to such tricks eventually went the way of the buggy whip and the 8-inch floppy disk. So why are we still facing the Y2K problem? There's no single answer. In some cases programmers were just lazy and used the old techniques. In others, they had no choice, such as when writing a new program that had to deal with these altered dates in huge databases, and their employers weren't able or willing to spend the time and money to update the database and all the programs that used it. This highlights one of the reasons why Y2K is so difficult and expensive to fix--most large computing environments depend on a lot of heavily interdependent programs and data, so even a single low-level change like adding those leading digits to a years will require changes throughout a lot of other software and data.

Enter Linux

The good news is that by and large, Linux and all other members of the Unix family tree are immune to the Y2K problem, since they keep track of time internally in way that's different from that described above. Instead of storing a month, a day, and a year as separate pieces of information, they simply keep a count of the seconds since January 1, 1970, and convert this to a more user-friendly format, as needed...such as when displaying the date a file was last changed. Even better is the news that the vast majority of Linux programs use this same method for representing dates, probably because it was easiest to simply follow the operating system's lead, so they'll also breeze right past 1/1/2000 with nary a hiccup.

This doesn't mean, however, that Linux doesn't have its own data issues. Because that counter Linux uses to store the number of seconds since 1/1/1970 can only hold a number so large (it's a 32-bit binary number, in fact), it will hit its upper limit and wrap around, much like the odometer on a car will go from all 9's to all 0's. This won't happen on Linux and other Unix variants until January of 2038, so we all have considerable breathing room. More important, long before 2038 we will have moved well beyond today's 32-bit systems, and Linux will very likely be changed to use a larger number to store that count of seconds. The next likely size is 64 bits, which will give us a counter so absurdly large it won't wrap around until sometime after the sun burns out.

What to Do

We should never jump to the conclusion that a computer running Linux, or any other operating system, is completely safe though. No matter how dates are stored in the operating system itself, the applications can do whatever they want, including resorting to the original date trick that started this Y2K mess, or inventing their own bizarre system for tracking time and dates. So, what should you do?

First, you should make an inventory of your system and all the software on it, and make sure you include the version number for each program. Then you should use the web to find the home pages for the various companies and developers who created your software, and see what they say about Y2K compliance. For Linux applications, you'll almost always get good news, and can simply check each program off your list. In particular, see http://www.gnu.org/software/year2000.html and http://www.gnu.org/software/year2000-list.html for information about GNU software and the Y2k problem, as well as the Y2K status of many of their programs.

But what if you can't locate the company or individual who wrote your program? or you can, and they won't supply any Y2K help? (This is a highly litigious issue, so some companies are very hesitant to offer any useful statements at all about their products' Y2K worthiness, for fear of being sued if they're wrong.) One simple way to test is to simply set the clock ahead on your system to sometime in January of 2000 and run your system. If you do this, please take the time to make a backup of your system, particularly your data, first! Nothing is cheaper than the insurance value of a system backup.

As you test, look for how programs read stored data, such as spreadsheets or financial information, how they handle displaying dates and reading them from your typed input, and how programs interact, if you feed the output of one program to another. These are the areas that are most likely to cause problems. In some cases, a program will let you enter a year as either two or four digits, and you can avoid problems by using the four-digit version. Some programs, like the cal utility in Linux, are immune to even this input problem, and will only accept four digit dates; the command "cal 5 99" will display a calendar for May of the year 99.

If you find a problem with a program, your first recourse is to contact the creator for a remedy. If that fails, then you have to find a replacement program, decide to do without that program entirely, or find a way to run with your computer's system clock set back a few years until you can find a more permanent solution. None of these are ideal answers, but it's better to know about a Y2K problem in advance than to be surprised by a malfunctioning system. Of course, this is all just a discussion of the software part of Y2K. There are also some problems with the BIOS and/or RTC (real-time clock) chip in some computers. Again, your best bet is to contact the manufacturer of your computer as soon as possible and find out what they have to say about your system.

For Geeks Only

If you're not afraid to download the source code for a program and compile it (and you have the Linux development tools installed on your system), you can also try Time Travel 1.0, available at http://www.aivazian.demon.co.uk/tt/tt.html. This is an interesting little program that lets you fool one program at a time into seeing a different time and date from the system. I downloaded and tested the program, using RedHat 6.0, and it seems to work as described. If you care to experiment with this, please follow the directions carefully.

Leapin' Lizards

While not a Y2K problem, another date-handling situation involves the fact that 2000 is a leap year, and some programs get this fact wrong. (A quick check of the documentation for one of Microsoft's programming tools showed two places where leap years were calculated incorrectly in sample code.) The problem is that some programs only use the "4-year" and "100-year" rules (years divisible by 4 are leap years, unless they're divisible by 100), and not the "400-year" rule (which says that a year divisible by 400 is indeed a leap year, after all).

It appears that this problem is far less prevalent and less disruptive than the Y2K bug. Still, if you routinely do things like calculate the number of days between two dates (which could be off by one if the range includes Feb. 29, 2000), it's worth checking the software you use for these tasks to make sure it doesn't have a problem.

Conclusion

The Y2K bug is a serious problem, and it's definitely something you should spend time to investigate, even if you use a computer only casually. The good news is that Linux and Unix users will, on average, have far less work to do preparing for January 1, 2000, or reason to worry than some others. But remember: 2038 is closer than you think...