Ruminations

Happy Leap Year!

Happy leap year to all of us! Leap years are an odd breed of being common enough that we don't make a big deal out of them, but infrequent enough that they are noted and become the subject of some dreadful jokes. And of course, anything that's not standard gets the attention of one form or another of scientists or specialists. For example, bissextile years (aka leap years) are also intercalary years. The ancient Egyptians, the epitome of all sun worshipers, had their own intercalary months of epagomenal days.

February 29th (aka leap day) isn't a big deal to most people. Some consider February 29th as a free day of rent, others see it as working a free salaried day that delays their month-end paychecks. Leaplings (those who are born on February 29th), who may or may not be desensitized to it, are the subject of quadrennial jokes (such as having fewer birthdays than the rest of us, and the jokes linked above). But to those of us who are programmers, leap year, and leap day specifically, have become the source of interesting tidbits and gotchas.

From a programming perspective, four years isn't a long time. But it's usually too far into the future to garner immediate attention or get a high priority. And yet, it tends to sneak up on us. This doesn't always give us enough time to properly test and address all the software issues that a leap year may bring.

Back in the days when the first programs were being written for personal computers, we sure could have used the internet. Leap years, as defined by the Gregorian calendar, turn out to be the origin of a variety of date related programming issues that continue to this day.

Not all programmers were on the same page when it came to calculating leap years. A misunderstanding by some, regarding the rules determining which years are leap years, has nagged us ever since. Basically, some programmers didn't think that the year 2000 was a leap year because it was evenly divisible by 100. And the rest, as they say, is history.

Leap years occur every four years, except when the year is evenly divisible by 100 (excluding years evenly divisible by 400, which are leap years).

These types of date issues don't just affect small companies or old systems. Here are some leap year issues that affected one of the most popular pieces of software ever: Microsoft Excel.

• The year 1900 was incorrectly set as a leap year to ensure Excel's compatibility with Lotus 1-2-3 (which had mistakenly set 1900 as a leap year).
• Its epoch date for PCs was set to Jan 1, 1900, and for Macintoshes it was set to Jan 1, 1904 (Macs didn't support years prior to 1904 yet). Prior to Office 2016, this difference caused dates to change by four years when moving files between PC and Mac. You can read more about the 1900/1904 date considerations if you're interested.
• The years 2100, 2200, etc. were set as leap years as well. This affected some future date calculations in spreadsheets. This bug was eventually fixed, but 1900 is still treated as a leap year for backward compatibility.

A quick flashback to our 2020 Hindsight post reminds us of what can happen when technology isn't ready for a particular date. And it doesn't have to be Y2k for some dates to be a problem. Case in point, 02/29/2024.

Here are a few examples of problems that happened this year.

• OpenAI's ChatGPT 3.5 wasn't sure if February 29th, 2024 was a valid date or not.
• Best Buy's online ordering removed February from the list of credit card expiration months a day early.
• Payment terminals in Sweden's ICA grocery and pharmacy stores failed to process transactions.
• There were some self-serve gas pumps in New Zealand that weren't working.
• Systems issuing drivers licenses in parts of Japan went down.
• Cybersecurity software vendor Sophos issued a warning about some of their products having issues with SSL certificates.
• Citrix issued a support article detailing crashes with its HDX HTML5 video service and its integration with Microsoft Teams.

Of course, the issues listed above weren't the only problems to be found. Some streetlights in Paris turned themselves off, Microsoft's "On This Day" feature didn't show photos from previous Feb 29ths, and Colombia's Avianca airlines printed tickets for the 29th with a date of March 1st.

Apps were not immune. Apple's Weather app reporting 30-day average precipitation as zero (for everywhere), popular budgeting app YNAB (You Need A Budget) couldn't track recurring transactions scheduled for the last day of the month, Berlin public transport's Android app reported trips on February 29th as taken on the 28th, and Irish Rail's mobile app couldn't show any routes on February 29th.

Some open-source projects were also affected. Phoenix Framework's web development platform, Coreboot's firmware project, Akami Unified Log Streamer and the Odin programming language all had date-related problems.

And lastly, smartwatches by both Titan and Amazfit had trouble displaying the date & time, and there were reports of issues with video games, including EA Sports WRC, Lilith's Throne, and Theatrhythm's Final Fantasy & Final Bar Line titles.

As you can see, date problems - whether it's as simple as leap year or as messy as Y2K - are some of the most persistent issues software must deal with. Some of the computer industry's date problems are created by poor planning and internal business procedures. Others are just old-fashioned bugs that got past QA.

The next anticipated date issue will be in 2025. This affects some older Japanese computer systems that have not been updated to use the Reiwa era calendar. Then we get to 2028, when we'll encounter problems with some signed byte ISO 9660 compliant optical-disc software. There's also Nova and Eclipse systems by Data General (which process applications for credit unions) hitting a 1900-based 128-year rollover. This may also impact some HP 3000 system. Oh, and let's not forget 2028 is a leap year.

With this leap year is behind us, we'll focus on more pressing issues and set some reminders for February 2028. Happy leap year!

---