Mimsy Were the Borogoves

Mimsy Were the Technocrats: As long as we keep talking about it, it’s technology.

Year 2000 Minority

Jerry Stratton, August 29, 1998

I appear to be in a minority where it comes to the Y2K, or “Year 2000” problem. I’m neither heading for the hills nor laughing at those who are. I think it is important to remember that Y2K is a problem. I originally wrote the following for independent comics creators/publishers; they—like any small business owner who is living week-to-week—are likely to be hit harder than most because they tend not to have money for upgrades. They’ll be using older software as well as older hardware. And this is the software and hardware that is most prone to Y2K problems.

First of all, you should be aware of what the Year 2000 problem is. It’s fairly simple, on the face of it: some computers and some computer software use double digits to denote the year: 98 for 1998, 99 for 1999 and… 00 for 1900. Note that there is no way of getting past the century marker in this system. This means that when the year hits 2000, such software will think that the year is 1900, and/or that future dates are based off of 1900 instead of 2000. So that, for example, your bill that is due the first day of January, 2000, was really due January 1, 1900, and you are 100 years past due. If you have ever tried to convince a creditor that their computer over-charged you, you know how serious this problem is.

As a side effect, some software that uses ‘0’ to denote ‘closed and done’ may, because of misapplied fixes to fix the Y2K problem, reopen accounts. For at least six months, Sallie Mae was listing my student loans as being due in the year 2000: because they used (I’m assuming) ‘00’ to denote that the loan was paid off. When they ‘fixed’ their system for Y2K problems, they went through and changed all ‘00’s to “2000”, including the ones that shouldn’t have been changed.

What you need to do to prepare:

First of all, start paying attention now. Look at the invoices and other paper documentation you receive for indications that the people you are doing business with will have trouble with Y2K. Indications might include incorrectly stating “2000” for closed or empty numbers, or indicating years in the early part of this century when they should be in the early part of the next century, or indicating negative numbers for the time between two dates instead of positive numbers. For example, if you have a contract that states that you will be working from 06/01/99 to 05/31/00 and that this means you will be working -1188 months, you may have a problem…

Note that just because you see “1998” in the date field doesn’t mean that the computer software that generated that date is good for Y2K issues, nor does it mean that seeing just ‘98’ in the date field means that the software is going to fail the Y2K test. First, sometimes software is poorly programmed on computer systems that handle Y2K just fine. Perl, for example, one of the major programming languages on the Web, handles Y2K fine. But during most of the nineteenth century Perl’s ‘date’ function looks like it is returning two-digit dates. It isn’t: what it is really doing is counting up from the year 1900. The correct way of working with those years is to add 1900 to them. But programmers familiar with the two-digit system will have their software written in Perl tack a ‘19’ to the ‘97’, ‘98’, and ‘99’ that Perl gives them, in order to generate ‘1997’, ‘1998’, and ‘1999’. But in the year 2000, 2001, and 2002, Perl is going to give them ‘100’, ‘101’, and ‘102’, and their software is going to generate the year ‘19100’, ‘19101’, and ‘19102’. Which will mean that your bill that was due on December 31, 1999 and which is one day late has 17,101 years of late fees tacked onto it.

Human beings will continue to abbreviate the year when the millennium rolls around and computers will have to deal with that. What is important is how the computer stores the date, not how it displays the date. The computer could very easily be automatically tacking on a ‘19’ to all dates (resulting in either the year 1900 or 19100 in 2000) or be converting the correct 1998 to the human standard of ‘98’ (which will continue to work just fine in 2000). Human beings are a lot smarter than computers, and most people will be able to tell at a glance whether that “00” means 2000 or 1900.

So you need to use this superior intelligence now to fix any problems before they become real problems.

Second, take an inventory now of all software that you use that is date dependent.

If you have a Macintosh, ensure that all of your software uses the Macintosh date and time routines, rather than its own. Most will, of course, use the built-in routines, since they work and programmers—the good ones, at least—are lazy. Well-written software that uses the Mac’s built-in date routines will be fine. Poorly written software will give you trouble on any platform. If you have a really, really old Macintosh, you may have Year 2038 problems. I understand that Macs last a long time but I do hope that by then you will have upgraded.

If you use Windows or DOS (or Unix-like operating systems on an Intel-compatible platform, or any operating system whose last upgrade was more than a few years ago), you will need to check both your hardware and your software. Web sites are a good choice for this. See if your software manufacturer and hardware manufacturer have a Y2K compliance page describing what version of the software is good for Y2K. In general you will find many more of your programs use their own date routines because this is all they had available when they were originally written.

It is not a good idea to roll your working computers around to 2000 and see what happens. If you are using date-dependent software, it will go ahead and give you 2-3 years of reminders, late notices, what-have-you, and then most likely mark those reminders as having been seen… and then you will have to painstakingly go through and fix them. Not fun. Even worse if this was the working computer for your customers who now get two years worth of late notices.

Finally, there is a lesser-known issue with year 2000: The year 2000 is a leap year. To those of you who know that leap years come every four years, this doesn’t come as a surprise, but you would be half wrong: on the century mark, even though it is always divisible by four, it is not a leap year… unless the century is also divisible by 400, which the year 2000 is. If your software takes into account the first two rules but not the final one, it will incorrectly tag the year 2000 as being a non-leap year.

As the year 2000 approaches, keep a closer and closer eye on your invoices and other date-dependent paperwork to make sure that the people you are dealing with are doing okay.

When the year 2000 hits, take very seriously all paperwork errors! If your bank tells you that you are 100 years behind payment on your business loan, be the first to call them up and wish them a happy 1900.

You might want to have contingency plans for all essential operations. If you are a publisher, consider making a plan to bypass your distributor if they bite the dust for a few days or a few weeks. If you are a retailer and are not completely satisifed with your bank’s assurances, you might want to have alternative cash reserves on hand to carry you through a week’s worth of comics or two week’s worth (or more, depending on how serious you perceive the problem to be). And remember that for most of us, having “cash on hand” means starting to save now and remembering to take a few weeks worth out before we need it. Don’t rely on your bank to be open. (I also wouldn’t recommend taking all your money out. If your bank isn’t back on line in a few weeks, your money is going to be worthless anyway.)

Remember that you can’t control what everyone else does. You may be perfectly Y2K compliant, but if your distributors, publishers, and customers are not, you will still run into trouble. In fact, I predict that the worst problems will occur when Y2K compliant systems get handed bad dates by Y2K non-compliant systems and vice versa.

Step 1 is to get your own house in order, step 2 is to prepare for what happens if your partner’s house is not. This is important, because one of the major software houses—none other than Microsoft itself—has a Y2K policy that brings to mind an old light bulb joke about them. They apparently include as Year 2000 compliant any software which has upgrades that are planned to be Year 2000 compliant. (How many Microsoft engineers does it take to screw in a light bulb? None: they redefine the standard to include darkness.) They have at least addressed the issue, albeit in their own style. Other software companies will not. And while you can control what software you use, you cannot control what software your business partners use. (As a side note, the first release of Microsoft’s “Windows ’98” operating system apparently solved the Year 2000 problem by having their software screw up on any New Year. Since it screws up on years other than Year 2000, it isn’t specifically Y2K non-compliant…)

If there’s one thing I’d like to leave you with on the Y2K problem, it is this: don’t think of it as a computer problem. Think of it as a standard emergency. Hell, I live in California. I have to worry about earthquakes. But every area has some kind of natural disaster you have to look out for. Are you prepared for an earthquake? Are you prepared for a hurricane? Are you prepared for floods and tornadoes? In other words, are you as prepared as you should be for a local shutdown of all services? These, unlike the Y2K problem, are things that will happen someday. If you’re prepared for these, then Y2K isn’t likely to present you a problem either. Make sure that you have access to all the essentials, such as required medicines, a supply of food and water, and a means of self-defense. And if you are a small business owner, make sure that if people want to buy from you, you have something to sell and a way to sell it. Be prepared for any emergency, not just man-made emergencies. We do not know that Y2K is going to be a major problem, but we are absolutely certain that California will have earthquakes, that Kansas will have tornados.

I do not think that the Y2K problem is nearly as dire as the worst predictions, but I also don’t believe it to be as simple as others claim. I suspect it will be a mere speed bump on the entrance to the 21st century. But I own a Macintosh and my bank has finally figured out that I don’t need to restart my student loans in 2000, so your mileage may vary. I’ll still be stocking up on food and water, and if you’d like to buy me a Christmas present in 1999, consider .40S&W in packs of 50.

March 13, 2000: Year 2000 Addendum

New Year’s Day 2000 has come and gone and most of the computer problems were solved, though we’re left with the real problem which is that we’ve trained software makers that bad is good. But why is the millennia such a big deal, anyway? Ask Cecil Adams!

March 8, 1999: The Real Y2K Bug

Point one is a simple one. The Y2K problem is not something you can put off until December 31. It will start appearing as soon as we start using dates greater than 1999. In some cases it has already started, but the biggest ‘jump’ in y2k problems before January 1 is going to be when fiscal years which overlap 2000 start kicking in this summer. Later on, products will start shipping with payment dates after 2000. You need to start paying attention now.

Point two is a rant. The biggest problem with Y2K is one of perception. I’ve been hearing this Y2K problem referred to a lot as a “bug”, as in the “Y2K bug” or “millennium bug”. It is not a bug. A bug is a mistake in programming. The computers are doing exactly what they were programmed and expected to do! The Y2K problem occurred because of a mistake in planning and a mistake in design. Programmers or designers, on writing software or building computers, made the decision or were given the decision to write software that only worked in the nineteen hundreds. Treating this as a one-time bug only sets us up for bigger problems in the future. We need to treat this as a basic problem in the way we decide how to design computer hardware and software. By treating it as a bug, we upgrade. By treating it as a design problem, we look for better design. By treating it as a bug, we’re rewarding companies who do things badly, over companies that do things right.

The most blatant example of this are the “Y2K budget lines” which are earmarked solely for use to fix Y2K problems. They are used to upgrade hardware and software which is not Y2K compliant, leaving less money for upgrading hardware and software which is Y2K compliant. At our University and across both business and education, this means that if you programmed or built non-compliant software and hardware, we’re going to give you more money... but if you programmed or built software correctly, we have to stick with the older versions because we haven’t got enough money after upgrading the bad software. We’re rewarding programmers and computer manufacturers for bad design. I’ve had faculty with Macs on their desktops beg me to tell our IS department that their decade-old computers are not Y2K compliant. Unfortunately, it just isn’t so. Since Apple built their computers right the first time, they can’t have any of our Y2K budget. I can’t imagine this kind of logic anywhere except computers. If Ford were to build cars that stopped working at midnight on December 31, 1999, our ‘motor upgrades’ would not replace our fleet of Fords with more Fords. If bad design on Ford’s part meant that we had to create a special “Ford 2000” budget line, we’d use that money with companies that build their cars right the first time.

The biggest Y2K problem of all is that we are training software companies that doing things wrong is better than doing things right.

  1. <- Idiot Virus
  2. Forward Looking Design ->