Y2k: a modest proposal

by now everyone, or at least everyone of any importance, knows that there is a problem in a lot of computers related to the rollover of dates at the end of this century. traditional date entries of two digits will very quickly be insufficient in determining a date. the rollover of ’99 to ’00 will effect many systems relying on date information, especially in calculations involving numbers of years difference. 2000 will behave, in some instances, like 1900, showing that, for example, my mortgage payments aren’t due for another 99 years. or else that they are overdue by that amount, and 99 years’ interest has accrued.

next year, according to all accounts, will suck. hard.

january 1 will leave innumerable people without power, money, credit, food, shelter, sanitation, or drinking water. so maybe that’s an exaggeration, but there will be some serious troubles come january 1, the full bulk of which won’t be uncovered until january 3 or 4, since the 3rd is the first monday of the year 2000, and the 4th is the first day most people will be staggering back to work after the hell-raising december 31 brought. nobody does any real work on mondays anyway.

and, as the deadline, and the breadline, draw ever closer for many of us, it becomes more and more imperative that we fix all those troublesome systems that have embedded year 2000 compatibility problems.

one solution to the programming mess is the brute force method: disassembling every piece of what, in computer/dog years, is ancient code line by line and patching every date call to be able to distinguish 2000 from 1900. in many cases this requires a full rewrite of large chunks of code that is written in the computing equivalent of sanskrit: COBOL. it’s a dead tongue, so dead that those few people that still spoke or studied it were ridiculed up until a couple of years ago when everyone who was born into the age of visual BASIC and C++ realized that capitalizing on the ‘Y2K’ bug was the only way they would ever make a buck, short of selling themselves and their burgeoning software companies to microsoft.

so, trudging through the rat- and rat-eating-snake-infested swamps of twenty- and thirty year old code is the main way in which the Y2K battle is being fought. There are bugs aplenty in the aged code, few comments to guide the way, patches of one sort or another all over the place from many generations of intrepid explorers blazing their own trails into the unknown. Then, by golly, there are the undiscovered tracts of lost code, those pieces that have been misplaced, filed, burned, buried, shredded, and mutilated to the point that they need to be replaced or rewritten entirely from scratch. some such endeavors are the equivalent of rewriting the Iliad in its original dialect, based entirely on the liner notes. who has time for all this?

my proposal is a much simpler solution. so simple in fact, i’m surprised no one has thought to do it before.

we must simply convert to hex.

yes, hex. beyond the simple limiting decimal system, hexadecimal notation has sixteen digits, including those of the outdated decimal system , and including the letters A through F. to the untrained eye, hex seems mysterious and even downright spooky. you got letters in my number system! you got numbers in my letter system! in fact, the untrained, unwashed masses are so unfamiliar with hex that i have, for years, etched the combinations of lockers and other combination locks directly into the lock itself in hex with no fear of anyone being able to unlock it. how do you dial in 1D anyway?

hex is a misunderstood child of the computer age, the most a lot of people ever learn of it is as a sidenote in math classes along with venerable binary.

however, if we were to convert wholesale to hex, next year would be 199A, giving us an additional six years to get systems 2006/19A0 compliant before returning to decimal. if programmers decided to be stubborn and put off updating their code to 4 digit dates, they would have 96 more years before 1A00 rolled around. of course, if we were to convert all 4 digit dates completely to hex, next year would only be 7D0, giving us only 48 years to prepare for 800. perhaps by that point we won’t even bother to convert back to decimal.

in some systems, changing the type of number a program works with is more economical than changing the number of digits it reads. a data entry of 00 will still illicit the dreaded 1900/2000 response, marking a difference of 1792 actual years, but it remains only to train those entering data to switch to hex, and convert all 00s to 9As. it’s as simple as changing to the metric system, and we know how successful those efforts have been.

Comments are closed.