Happy Leap Day!29 February is causing problems in software systems across the globe. It’s a good reminder on how few assumptions we should make about dates – and why to use a date library when you can.
👋 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:
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:
Payment terminals at gas stations stopped working in New Zealand. The New Zealand Herald reports:
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:
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:
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:
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:
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:
Featured Pragmatic Engineer Jobs
See more senior engineer and leadership roles with solid engineering cultures on The Pragmatic Engineer Job board - or post your own. Hire Faster With The Pragmatic Engineer Talent CollectiveIf you’re hiring software engineers or engineering leaders, join The Pragmatic Engineer Talent Collective. It’s the #1 talent collective for software engineers and engineering managers. Get weekly drops of outstanding software engineers and engineering leaders open to new opportunities. I vet every software engineer and manager - and add a note on why they are a standout profile. Companies like Linear use this collective to hire better, and faster. Read what companies hiring say. And if you’re hiring, apply here:
You’re on the free list for The Pragmatic Engineer. For the full experience, become a paying subscriber. Many readers expense this newsletter within their company’s training/learning/development budget. This post is public, so feel free to share and forward it.
|
This week’s system design refresher: Top 9 Most Popular API Protocols (Youtube video) What is a deadlock? What’s the difference between Session-based authentication and JWTs? Top 6 ElasticSearch Use Cases Top 9 Cases Behind 100% CPU Usage SPONSOR US ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ...
Comments
Post a Comment