Happy Leap Day!
👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover topics related to Big Tech and startups through the lens of engineering managers and senior engineers. In this article, we cover one out of three topics from today’s subscriber-only The Pulse issue. Subscribe to get issues like this in your inbox, every week.
It’s 29th February, a once-every-four-year occurrence. Most people don’t think too much about this extra day in the calendar, but as software engineers, we absolutely should! But first, a few current cases of systems whose developers didn’t:
In Sweden, card payments are down at a leading supermarket chain. ICA is the biggest supermarket chain in the Nordic country, and today customers can only use cash. From Swedish online magazine Omni.se:
“The problem [with card payments] is due to today's date. The information I received is that today is the shooting day. It is therefore a leap day problem and it is February 29 that simply causes it, says store manager Peter Slagbrand to Eskilstuna-Kuriren.
The information about the leap day problem is confirmed by the ICA bank's press officer Maria Elfvelin.”
In Colombia, airline tickets have been printed incorrectly by the nation’s largest airline. Airline Avianca printed tickets dated as 3/1 instead of 2/29, thanks to their system not accounting for the leap day. A traveler shared how the airline recognized the mistake, fixed it on the day, and sent this email to customers:
“We inform you that if your flight is on February 29, 2024, you may experience a discrepancy in the date of your flight on the boarding pass. To ensure you have the correct information, please download it again from avianca.com or from our app.”
Payment terminals at gas stations stopped working in New Zealand. The New Zealand Herald reports:
“Petrol stations around the country are up and running again following a day-long leap-year glitch which saw card payment machines go down for more than 10 hours.
Allied Petroleum, Gull, Z, Waitomo and other fuel stops around New Zealand reported problems with card payments on Thursday because of a software glitch they said was caused by their systems not being programmed to deal with the date February 29.”
A smartwatch released this year couldn’t display today’s date. The Fastrack FS1 is a recently released smartwatch from the Indian company, Fastrack. The FS1 model was released in March 2023, and here’s what it says is the date today:
An EA Sports racing game is unplayable today. EA SPORTS WRC (World Rally Championship) is a rally racing game, released in November 2023 for Windows, Xbox and Playstation. Those trying to play the game today cannot: because it crashes. The workaround EA Sports suggests is to set your system date to 1st of March – or perhaps just take a break from playing today!
This crash is notable, given the games industry invests more heavily than most other companies into quality assurance and thorough testing of the games. It is further proof on how easy it is to forget about an edge case that comes up just five months after the release of the game.
Driving license issuance disrupted in Japan. Japan Today writes:
“Police departments in some Japanese prefectures were unable to issue driver's licenses Thursday, apparently due to a system glitch linked to the leap year. The extra day at the end of February appears to have triggered a system error related to time and date functions.
Police departments in Niigata, Kanagawa, Okayama and Ehime prefectures faced problems from the morning, such as being unable to send personal data from the driver management system to the machines that issue licenses. The system was almost fully restored before noon.”
I will give a hat tip to the “almost fully restored before noon” mention. You can imagine the engineer who was asked by a business stakeholder: “is it fixed yet?” and who answers: “Almost – I’ve now resolved 90% of the issues.” Which we all know means there’s still the second 90% left to resolve – because resolving those last edge cases often take just as much time as fixing the first 90% did! I’m being sarcastic, but this is often how it goes with bugs not encountered before.
There are several more cases of systems failing today, as collected by software engineer Matt Johnson-Pint in his post, List of 2024 Leap Day Bugs.
Expect more bugs this 31 December. After 29 February, we’re not done with leap day-related glitches. New Year’s Eve holds another nasty surprise for systems that assume a year is 365 days long. This year has 366 days.
Some consequences can be very serious. In 1996, an aluminum smelting plant in New Zealand was damaged when the factory abruptly shut down in the first few seconds of 31 December! As the New Zealand Press Association wrote in 1997:
“A computer glitch at the Tiwai Pt [place in South Island of New Zealand] aluminum smelter at midnight on New Year's Eve has left a repair bill of more than $1 million [New Zealand Dollars]. Production in all the smelting potlines ground to a halt at the stroke of midnight when the computers shut down simultaneously and without warning.
New Zealand Aluminium Smelters' general manager David Brewer said the failure was traced to a faulty computer software programme, which failed to account for 1996 being a leap year. The computer was not programmed to handle the 366th day of the year, he said. "Each of the 660 process control computers hung up simultaneously at midnight," Mr Brewer said.”
The same problem occurred two hours later at Comalco's Bell Bay smelter, in Tasmania [Australia]. New Zealand is two hours ahead of Tasmania. Both smelters use the same programme, which was written by Comalco computer staff. (...)
Tiwai staff rallied through the night to operate the potlines manually and try to find the cause. The glitch was fixed and normal production restored by midafternoon. However, by then, the damage had been done. Without the computers to regulate temperatures inside the pot cells, five cells overheated and were damaged beyond repair. Mr Brewer said they would have to be replaced at a cost of more than $1 million.”
In 2008, Zune (Microsoft’s 30GB music player) stopped working on 31 December because of a leap year bug, which sent devices into an infinite loop. At the time, Microsoft had invested the most into a testing culture, with one dedicated SDET (software development engineer in test) for every 2 SDEs (software engineers.)
Yet this bug slipped through the cracks! We cover more on Microsoft’s QA approach and the later retirement of the SDET role in How Big Tech does Quality Assurance.
So, how do you account for Leap Days when building systems? A couple of things will help:
- Use Date objects and operations on them: e.g. increment the date object by a year, instead of adding 365 days to it. Framework-level date classes tend to account for leap years – it’s a big reason to use them!
- Do not assume February always has 28 days
- For that reason, don’t assume every year has 365 days
This list is not exhaustive. What is exhaustive is a list on GitHub: Falsehoods programmers believe about time. It’s a very long list, with 112 falsehoods named. Here are 10 of my favorites:
“Don't reinvent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.
Falsehoods
- There are always 24 hours in a day.
- February is always 28 days long.
- Months have either 28, 29, 30, or 31 days.
- The day before Saturday is always Friday.
- GMT and UTC are the same timezone.
- Any 24-hour period will always begin and end in the same day (or week, or month).
- The difference between two timestamps is an accurate measure of the time that elapsed between them.
- Daylight saving time always adjusts by an hour.
- Time always goes forwards.”
The last note is particularly notable on how time can move backwards – at least in terms of what the time is. While the absolute seconds will always will always increment: when daylight savings end, clocks are winded back an hour: one minute after 1:59am on Saturday, it is not 2am but 1am!
There are some things, however, that are safe to assume, because they are always true. For example, a month always has at least 28 days. So, if you are to hardcode a monthly recurring charge to repeat on a specific day of the month: doing this on or before the 28th should be safe enough.
I now invite you to read the full list, then inspect code you’ve previously written containing assumptions about dates and time. Can you replace it with a date library that accounts for (hopefully) all of the above?
This was one out of the three topics covered in this week’s The Pulse. The full edition additionally covers:
- Klarna’s AI chatbot: how revolutionary is it, really? Klarna launched its AI chatbot, built in collaboration with OpenAI, which the company wants to use to eliminate 2/3rds of customer support positions. But is it as revolutionary, and as likely to replace jobs, as Klarna claims? My take is that it’s a well-written bot, but I’m dubious that it’s as disruptive as that.
- Affirm paid $10M for Fast’s engineering team. As the one-click startup ran out of money, its then head of engineering brokered a deal with buy-now-pay-later scaleup Affirm, which paid $10M in cash in return to give out offers to 80-90 Fast software engineers.
Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.