Extra day, extra bug: leap years in software development

In our digitalized world, where data and time measurements play a central role, a small calculation error can lead to major problems in software and IT systems.

In a leap year, systems can be more susceptible to such errors as the calendar includes an extra day in February. For us humans, this seems to be a trivial issue. However, a machine or software is much less flexible here and requires a clean implementation in the handling of date data.

Join us on this short but fascinating excursion, which we owe to the leap year. If a system does not work as expected on 29 February, you already have a first clue as to what the problem might be. (And yes, the images below were generated using ChatGPT).

What exactly is a leap year?

To do this, we need to dig a little deeper: a year on earth, i.e. a 360° orbit around the sun, is slightly longer than 365 days, namely exactly 365 days, 5 hours, 48 minutes and 45 seconds.

This length of time is also described as a “tropical year”. In order to prevent a long-term shift in the seasons, an additional day is inserted every few years on 29 February. Roughly speaking, the leap day appears in the calendar every four years. Strictly speaking, there is the Gregorian leap day rule. This consists of three rules and defines leap years as follows:

1. The years divisible by 4 are leap years, with the following exceptions:

2. Secular years, i.e., years that conclude a century, are not leap years, with the following exception:

3. Secular years that are divisible by 400 are considered leap years.

Accordingly, the years 1992 (1st rule) and 1600 and 2000 (3rd rule) are leap years. The year 1900 (2nd rule), however, does not fall into the category of a leap year because it is a secular year that is not divisible by 400.

In addition to the leap year, there are also other corrections, such as the leap second. They help to synchronize the coordinated universal time with the actual rotation of the earth. However, this will not be discussed further in this blog, as it has nothing to do with the leap year. Just keep in mind that it has similar consequences and also occurs at irregular intervals. Incidentally, the last leap second was inserted on 1 January 2017 at 00:59:59 (Swiss time).

Why is the topic of leap years being addressed?

For many of us, 29 February is just another day in the calendar like any other. Unfortunately, this is not so easy to map in software and regularly leads to problems and system failures, so-called leap year bugs.

And no, these incidents are not limited to small companies and their services. For example, the widely used programming language PHP skipped 29 February when the following code snippet was used to format dates in the software: DateTime::createFromFormat. This bug was reported in 2012 and not fixed until 2021.

Furthermore, a leap year bug at Düsseldorf airport caused the baggage conveyor belts to fail in 2016. As a result, 1200 pieces of baggage were not loaded onto aircrafts.

Google and Microsoft have also had to deal with leap years. In 2012, Google’s mail service accidentally displayed 31 December 1969 for all chats saved on 29 February. In the same year, Microsoft’s Azure services went offline on 28 February due to a leap year bug. As you can see, this extra day is quite something.

You can find more incidents here: https://codeofmatt.com/list-of-2020-leap-day-bugs/.

As was the case 4 years ago, new leap year bugs are sure to emerge this year too.

What causes the leap year bug?

Unlike us humans, machines are definitely less flexible with an extra day at the end of February.

Depending on how the dates and times are handled in the software, especially when calculating and manipulating them, a bug can quickly occur. The correct calculation of leap years is essential. If this is not implemented at all or is implemented incorrectly, this can lead to significant system errors, as described above. For example, it could be incorrectly implemented that all years that are divisible by 4 are classified as leap years with a 29th February. Admittedly, such an implementation would probably work without any problems for the next 76 years up to 2100. Nevertheless, it is incorrect handling that could potentially lead to problems.

Furthermore, it is possible that a constant length of 365 days is assumed for a year in software. This can lead to complications, especially if (daily) interest is calculated or if scheduled or planned tasks are to be executed and, in the worst case, to a crash. Date manipulations can also be a source of bugs if leap years are not taken into account. For example: If you had planned a task on 1 March 2023, which should also run again in one year on 1 March, and thus added a year or 365 days to the old execution date, this would result in 29 February. Conversely, if a task is scheduled on 29 February to run in a year’s time, the software can set the task to 29 February 2025 if implemented incorrectly – a date that will never actually exist. These are just a few examples of how a leap year bug can occur.

How do we prevent a leap year bug?

Complete protection against the leap year bug is possible, but difficult to achieve and, depending on the software, not even necessary. Correct implementation of a leap year algorithm is already a major and important step. This must include the three leap day rules described above.

In addition, robust programming techniques and extensive testing are necessary to ensure that the data handling works correctly. If an API is used to manipulate data, it is important to know how this interface handles such manipulations and leap years.

If you are working on an application or a web tool and want to make sure that no unwanted (leap year) bugs occur, then get in touch with us.