Looking Back At The Y2K Bug by Paul Lynham FIAP

A quarter of a century ago, projects to address the problems of software that used two-digit years were well on their way to completion. This was a problem that I also tackled in my own agricultural software which I had developed in the 1980’s. It was written in Turbo Pascal and targeted MS-DOS and compatible operating systems (such as PC DOS and DR-DOS). Therefore, I will focus on PC software, rather than software running on mainframes and minicomputers of that era.

By the late 1990’s | had been using Delphi to develop object-oriented software targeting MS Windows, but many of my customers were still using MS-DOS and thus the need to update the legacy software. There was no problem with dates in

Delphi as this was an inbuilt data type and it also came with its own date manipulation methods, which is of course something which goes without saying in modern development environments. However, previous to this, most developers would have written their own date manipulation routines.

In the 1980’s, memory was at a premium and a typical IBM PC or compatible machine would have 512 or 640 kB of RAM, of which around 70 kB would be used by the operating system, leaving as little as 440 kB for your application to run. Therefore, using two-digit dates was a typical way of saving bytes. However, by the late 1990’s the problem of how to deal with the new millennium was looming and changes were needed to allow these dates to be stored and handled reliably. As an example, if a two-digit year with a value of 03 was stored and then brought into working memory, would this be translated as 1903 or 2003? This was at the heart of the problem.

In essence, there were several ways of tackling this issue, the obvious one being to update all two-digit years to four-digit years. However, this was not as easy as it first seemed. Different systems encoded dates in different ways and besides updating date handling routines to cope with the new four-digit years, the stored data would also need to be updated.

If a SQL database was used to store the data, then this could make this task easier. However, at that time there were many ways of persisting data, including proprietary commercial software (often called Toolboxes) or some custom storage software. Therefore, this change could involve a laborious process of creating new storage structures with the new dates having four-digit years and then reading the old data stores, translating them to the new format in memory and then writing them out to the new structures. This process has many moving parts and there is plenty of scope for things to go wrong.

My software had a much simpler solution and I decided not to touch the stored data, but instead update the decoding routines. I could do this because typically livestock do not benefit from the comparatively long lifespan of humans. As an example, a human could be born in 1898 and be alive in 2003, thus their life spanning three centuries. You need to know the century in this case as assuming it is 1900 would cause problems (a person being 5 instead of 105). There is also a need for future events, so a person born in 1998 may not get a state pension until 2068 and other types of events may go well into the future. Hence a good range of dates is required, and applications using historical dates may need thousands of years. However, a typical cow or sheep would be unlikely to achieve 20 years and so the issue became easier for my software.

Copyright © Paul Lynham 2024