Tim Hawkins' Year 2000 Solution

(For 260 years or more anyways.)

       The flurry of news coverage of the upcoming year 2000 computer problems recently attracted my attention.  As I understand the problem there are thousands of programs and databases throughout the world that store the year in a 2 digit record.  Having limited knowledge of programming and no specific knowledge of the multitude of programs and data files affected, I decided to try to develop a generic solution that would minimize or eliminate changes to the data records themselves.  Although I have written programs in basic, cobol, lisp, and pascal I am not a professional programmer so do not expect to find neat lines of code on this page.  If there is a huge outcry for me to demonstrate that this technique works, and it does, I will consider supplying a small stand alone program for the skeptics who would require such a demonstration.

        So then the problem became how to signify the year 2000+ to a computer program in a 2 digit field in a methodical manner.  While pondering the situation I decided to do some research via the Internet and was astounded that some experts have estimated this to be a $400 billion to $600 billion problem!! Therefore any solution I came up with would have to be quick and easy to implement.

        The solution I have is VERY simple and very easily implemented when compared to the mainstream alternatives.  Use something else, a code, in the 2 digit record and let the program do a small amount of in and out translation to the data file.  For this illustration, and for the sake of simplicity, I will use the capital letters of the alphabet as the first digit and the numbers 0-9 for the second digit of the code.  In order for the data files to store this code the 2 digit field must be alpha-numeric and cannot be numeric, but the values already stored away in datafiles now, 68 for the year 1968 let's say, need not be manipulated in any way beyond a one time adjustment to the data field itself to make it alpha-numeric and perhaps a quick translation of the number 68 to the text 68.

         Using the 26 capital letters of the alphabet as the first digit of the code and the numbers 0-9 for the second digit of the code would solve the problem for 260 years!  That is through the year 2259, which includes years 2000 (A0) through 2259 (Z9).  The code would work like this.

         The computer operator would enter the year as a 4 digit input and the program would translate that input into the appropriate code.  When the running program used the code for a year it would simply take the code as stored, run it through whatever translation method necessary to get the true year, then continue on with whatever calculations the program was making.

         One very simple way to implement that translation would be through a lookup table and to illustrate this I have built a simple Lotus 123 spreadsheet which you may retrieve here and it will also work in Microsoft Excel. (This should be the method of choice for both EBCDIC and ASCII character set based systems especially when coding beyond 260 years.)

         A second way to implement this translation, for ASCII character set based systems, would be to divide the 2 digit record and use the ASCII values of the first digit to calculate the year.  The ASCII code for a capital A is 065, B is 066, ... and Z is 090.  So here's how it would work for year 2000 aka code A0.  A0 divided up gives us A (ascii code 065) for the first digit and 0 (zero from the value of the string) for the second digit. Using 135 as our "offset" ((2000/10)-065=135)  the math boils down to this:  (offset + ascii_code_first_digit) * 10 + integer_value_second_digit.  In this case  A0 = (135+065)*10 + 0 = 2000.  In the case of B0 which we know to be the year 2010.  B0 = (135+066)*10 + 0 = 2010.  Converting a year into it's correct code is simply a matter of reversing the above process.

   A0 = (135+065)*10+0 = 2000           A1 = (135+065)*10+1 = 2001

   Z0 = (135+090)*10+0 = 2250            Z1 = (135+090)*10+1 = 2251

        Some simple input checking to restrict the valid input ranges between the years 1900 - 2259 would be necessary.  And some program logic to ensure the above calculations are only performed on records that start with capital letters, aka ascii codes 065-090.  If the record does not begin with a capital letter then it would be converted to the numeric value of the string.  The text record  '68'  would simply need to be converted to the number 68.

        The EBCDIC character set is strangely staggered in it's sequencing of the capital letters.  A-I are decimal 193-201, J-R are 209-217, and S-Z are 226-233. And the gap between the 3 sets of contiguous groups are not equal.  The gap between 201 and 209 is 7 but the gap between 217 and 226 is 8.  While an equation to convert coded 2 digit years into the actual value of the years may be possible via nested if-then-else statements or by an elaborate loop of some sort it wouldn't be easy.  The lookup table approach mentioned  above is very straightforward and should be utilized instead.

       Using just the numbers 0-9 and letters A-Z and letters a-z to code years beyond 2000 we can code to the year 5743!!  As shown above using A0 - Z9 takes care of 260 years,  a0-z9 would cover another 260 years.  0A-9Z would cover another 260 and 0a-9z yet another 260 years.  So far that totals 1040 years worth of 2 digit codes by using one letter, either upper or lower case, and one numeral in the code.  By combining two letters in the code another 2704 codes can be made.  Each letter of the alphabet when coupled with another letter of the alphabet into a 2 digit code can produce 104 different codes.  For instance the letter a would be used like so,  aa ab ac .. az for 26 codes, aA aB aC .. aZ for 26 codes, Aa Ab Ac .. Az for 26 codes, and AA AB AC .. AZ for another 26 codes.  For a grand total of 104 codes that start with either an upper or lower case A(a) and the second digit is also an upper or lower case letter of the alphabet.  104 codes per letter times 26 letters equals 2704 codes.  1040 + 2704 = 3744 and 3744 years into the future from 1999 is the year 5743.

        Note:  A lookup table is the only practical way to encode and decode the years if this technique is taken to this extreme.

        I am 100% sure that there are other techniques for coding the years into 2 digit records. You can find more ideas at mitre.org.

       This approach addresses a number of concerns with the year 2000 problem.

• Allows existing databases to be maintained with only the possible need of converting the 2 digit year record from numeric to alpha-numeric.  I say "possible" because for all I know the field could already be alpha-numeric.

• Being able to maintain existing databases frees programmers from writing database translation programs and allows them to concentrate their efforts on the minor code modifications needed to implement this solution.

• "Solves" the problem through the year 2259 and beyond.  I would guess that in 260 years most of these applications and databases will be long forgotten.  If nothing else this solution provides 260 or more years to permanently solve the problem rather than the 2 years we currently have.

• Comparatively simple and easy to implement as I have shown above.

• Of course this method would require a some programming effort to implement but not as much effort as the alternative of totally re-doing every program and every data record everywhere to handle 4 digit years, which will only postpone the problem again until 9999.  No doubt that will be dubbed the Y10K problem.

Accesses: