Question: Will 2100 be a Leap Year?

Intro

If you answered “Yes” to the above question, here’s something interesting that I rediscovered recently while I was teaching an online Cobol programming course in the midst of the pandemic: The 2100 Leap Year Bug. While not as immediate a threat as Covid-19, it is still something to keep in mind, especially if you are (or know someone who is) involved with Risk Management, Business Continuity, Regulatory Compliance, and IT Governance in organizations with extensive core legacy (aka Cobol) systems.

What’s in a year

Just to make sure we’re all on the same page: The solar year is the time required for the Earth to travel once around the Sun. This interval is divided into and mapped out to the solar year calendar as 365 equal units, or “days”, with each day meant to consistently align with the same tropical season, year after year.

However, the time interval of a solar year is actually closer to 365¼ days, and since the calendar can only express full days, not partial days, a quarter of one day would go unrepresented in the calendar each year. Over time, if this gap was not adjusted, it would eventually lead to a misalignment between seasons and calendar months. For example, Summer might commence in December, Winter in July. Other calendar systems have similar alignment issues, and most have devised a similar remedy based on adding to the calendar and “making up” for lost time.

Experience is the teacher of all things

This above saying has been attributed to Julius Caesar, who also introduced the Leap Year Rule, which was made to adjust for the yearly quarter-day gap. This would be accomplished by adding one extra day to the solar year calendar, once every four years, to “make up” for the four quarter-days “lost” over four years. The one year out of every four years designated to have the extra day added to it would be known as a Leap Year, and would be determined by its numerical value being a multiple of four (or divisible by four — meaning that dividing it by four would yield a remainder of zero). Thus the leap year would have 366 days instead of 365 days, and the extra day would be added to the shortest month — February — so that in a leap year February would have 29 days instead of 28.

Problem is

The precise time interval of a solar year is not exactly 365¼ (or 365.25) days, but rather 365 days, 5 hours, 48 minutes and 46 seconds (or 365.242 days). In order to make up for the precise time gap, an exception was added to the leap year rule:

a year that was divisible by four would not be considered a leap year if it was divisible by 100 — unless it was divisible by 400.

Houston, do we have a problem?

I checked with a number of colleagues in different countries to see if their core legacy (aka Cobol) systems had complied in full with the Leap Year Rule, including the 100/400 year exception. Almost all reported that in most cases they had checked, their programs determined a leap year by dividing by four only. It seemed they were unaware of the exception whereby you need to divide by 100 and 400 as well.

In other words, it is quite possible that in many organizations, the years 1800, 1900, 2000, 2100 and so on are always considered to be leap years, having 366 days instead of 365, and February 29th would be a valid date in those century years.

Based on the nature of an organization’s business and historical records, century years from 1900 and below are probably not going to be impacted by the flawed implementation of the Leap Year Rule. And thankfully, the year 2000 actually was a leap year, as it is divisible by both 4, 100 and 400. This limits the problem down to the year 2100 and beyond.

Y21K

It is now clear that most core legacy systems will be computing the year 2100 incorrectly as a leap year with 366 days and February 29th as a valid date.

While it can be expected that these systems will have been replaced by the time the year 2100 arrives, depending on the nature of each organization’s business, future projection calculations (such as those for interest, loans, savings and so on) performed today and in the coming decades, could at some point reach the year 2100, and possibly have implications. This is of course something each organization will need to explore, analyze and decide if and how it should meet this challenge. The first step could be simply scanning the relevant system sources to get a feel for the magnitude and effort that may be needed to mitigate the issue.

Prologue

While writing this article it dawned on me that an even more urgent Y2K related issue could become a reality that needs to be addressed sooner than the Y2.1K issue discussed here. You can read more about that in PART 2 where I write about the risk related to Date Windowing.

Acknowledgement

When I came across this 2100 Leap Year issue, the first thing that came to mind was Y2.1K After a day or two, I said to myself: That can’t be, somebody must have coined that term before me… I searched and found an article by Paul Ryburn from 2008 where he brought up the 2100 Leap Year issue.

I later found that Y2.1K was being used in a general “next version” context of Y2K, usually having to do with other related issues stemming from formatting, storage, operating systems and hardware, that had a similar effect to the classic Y2K bug, such as the 2038 Unix time issue on 32-bit machines (aka Y2K38).

All in all, I found this, as Spock would say, “Fascinating”.

Dov Keshet has been designing and developing award-winning core business and infrastructural solutions in large organizations for over 35 years. He has served as technical lead and architect in the development, integration and migration of information systems predominately on the IBMi (aka iSeries or AS/400) platform.

Feel free to contact me at dovk@cobol.ninja or via LinkedIn. If you have any specific R&D or training needs, you can contact me via Fiverr