Home / Advisory / Is there a Similar Y2K Phenomenon looming on “01 January 2020”: Is there a Risk of Y2.02K on IT Systems?

Is there a Similar Y2K Phenomenon looming on “01 January 2020”: Is there a Risk of Y2.02K on IT Systems?

Posted on
01 January 2020, is again a similar nightmare for many IT System Engineers, as was the scenario on 31 December 1999.

01 January 2020, is again a similar nightmare for many IT System Engineers, as was the scenario on 31 December 1999. The end times of 31 December 2019, may be the will beginning of a technological failure for many system across the globe, for the very fact that these systems have the inability to enter into a new decade with a matching thousands and tens place in the “Year” format of ‘Date’ in the Database of IT Systems.

The Date format was an issue on 01 January 2000, and there were programmers who were on round-the-clock duty to address the issue of ‘system crash’ or ‘erratic computer behavior’ due to incorporation of the “DD-MM-YY” format in computer systems instead of the “DD-MM-YYYY” format. The IT Engineers had then, tweaked the Legacy IT systems by adding another field in the database and with this method was able to identify the century using a ‘reference year’, with an additional column that was added during the ‘problem solving’. This method call “Windowing” was used to facilitate the construct of the ‘Date Field’ in the ‘Database’ and through this design the banks and other institutions were able to continue to use the ‘two digits’ to specify the date in programs.

Windowing was used as a temporary fix, with an aim to tide over the Y2K problem that had to be encounter, post the year 1999, and was expected to work till the legacy system was replaced in organisations that were using them. Two-digit years were used in the 1970s when CPU, memory and storage were very limited and expensive. Windowing was resorted to as a temporary measure for Y2K because it was the only immediate ‘Incident Response’, and the most viable low cost option.

The Envisaged Problem

As explained earlier, if the Y2K handling in a legacy database, where the system was formatted to “DD-MM-YY” format, was handled by adding ‘reference year’ column with a value set as “20”; then there may be a ‘referential year’ problem on “01 January 2020”, as the system will now take the incremented value as “21”, after “20”. Hence, we see that instead of populating the ‘year’ as “2020”, it will read as “2120” (if only decade syntax was handled during the Y2K scenario). Also, we see that instead of populating the ‘year’ as “2020”, it will read as “1920” (if decade or century was not handled during the Y2K scenario). Further, there are possibilities of the system reading the current date as “01 January 2120” or as “01 January 1920” instead of “01 January 2020” in many of such legacy systems where the date format is not coded to “DD-MM-YYYY” format.

This will also result in the wrong calculation of “age” of individuals or assets, or even “manufacture date” of products, or even astronomical calculations. In-turn, the problem of Y2.02K is envisaged on such legacy systems on the 01 January 2020.

This aspect also has an implication on Security Issues and Patch Management. The field of Digital Forensics is also known to be influenced by this wrong date capture. The “Artifacts” that refer to ‘Time Stamp’ in ‘digital mappings’ and ‘Timelines’, may also show erratic behaviour while being referred-to in Digital Forensics.

An example:

Let us take for example, the age for retirement of an employee is to be calculated:- The individual was born in the year ‘1985’, and the age as on year “2020” should be “35”. Further, if the system is to address the current date as “1920“(on 01 January 2020), then the age will show a negative value of “-65”. Also, if the system is to address the current date as “2120“ (on 01 January 2020), then the age will show a positive value of “+135”. In both these instances the calculation is drastically wrong. At this point the wrong century is applied to the two-digit year and the current year drops backwards by 100 years, so 2020 becomes 1920; and if the decade aspect was addressed then the current year goes forward by 100 years, so 2020 becomes 2120.

The Fix

Post the Y2K scenario, may organizations, had addressed the issue and had migrated to the “DD-MM-YYYY” format from the legacy “DD-MM-YY” format. However, where the incremental response was resorted while handling the Y2K aspect in that legacy system; the issue of the presently envisaged “Y2.02K” is sure to strike again. Many organizations had invested time and money during the Y2K era and had plugged the problem back in the year 1999 or in the early 2000; however those systems that run on the legacy IT infrastructure will need to address the problem before the advent of ‘Date’ “01 January 2020”.

Though the scenario is not as grave as that which existed in the 1999, yet the fix is available as code migration and use of ‘Big Data’ (through the principle of Hives) can handle this issue. There is also a work-around, for those applications that are still using the Legacy IT Systems, but this will entail a detailed ‘System Study’ and ‘Coding’ effort.

Top
%d bloggers like this: