Are you prepared for leap year bugs?
The last leap year, February 29, 2024, was a busy day for IT teams. Support queues filled up fast as businesses discovered their software couldn’t handle the date. Fuel pumps across New Zealand went offline for more than ten hours. Citrix’s virtual desktop service stopped working on the leap day. Sophos triggered unexpected security certificate warnings. A Colombian airline printed boarding passes with the wrong date. Japan’s police couldn’t issue driver’s licences in four prefectures. And in Zürich, an entire city’s payroll system misfired.
The leap year bug is not a relic of the Y2K era. It shows up every four years, on schedule, and catches businesses off guard each time. The next leap day is Tuesday, 29 February 2028. That gives you just under two years to check your systems are ready.
At TTA, we work with professional services businesses across Queensland who rely on date-sensitive software every day. The pattern we see is familiar: most businesses assume their vendors have handled it. Some have. Many have not.
What the leap year bug actually is
The leap year bug occurs when software handles dates without correctly accounting for the extra day added in February every four years. The underlying issue is simple: the Earth takes roughly 365.25 days to orbit the sun. To keep the calendar aligned with the seasons, an extra day is added to February in years divisible by 4 (with an exception for century years not divisible by 400).
Software fails in two main ways. The first is an outright error: the code tries to create a date of February 29 in a non-leap year and crashes. The second is silent corruption: the code assumes every year has 365 days and produces wrong results without any obvious error. Both types cause real problems. The silent ones are often harder to find.
What went wrong in 2024
The 2024 leap day produced a long list of failures. A few that affected businesses directly:
- Fuel payment terminals (New Zealand): Self-serve card payment systems at Allied Petroleum, Gull, Z Energy, Waitomo, BP and others failed for more than ten hours. Customers couldn’t pay at the pump. The fault was confirmed as a leap year bug in Invenco point-of-sale software.
- Citrix virtualisation: The HDX HTML5 Video Redirection Service failed across Virtual Delivery Agent machines. Remote desktop environments used in professional services, education and call centres stopped delivering video. The workaround required manually rolling back system clocks on every affected server.
- Sophos security software: Sophos Endpoint, Sophos Server and Sophos Home produced unexpected SSL/TLS certificate validation warnings when devices were rebooted on the leap day. Sophos disabled SSL/TLS decryption across its customer base to prevent widespread disruption.
- Airline boarding passes: Avianca, Colombia’s largest airline, printed boarding passes dated March 1 for flights that departed February 29, because the ticketing system did not recognise the leap day.
- Driver’s licences (Japan): Police in four prefectures, including Kanagawa and Niigata, could not issue or renew licences on February 29 and had to switch to backup systems.
- EA Sports WRC: A video game released in November 2023 crashed on launch on the leap day, just five months after release, despite the games industry investing heavily in quality testing.
The recurring theme: systems that were working perfectly the day before failed because they had never encountered February 29 in their operational life. That five-month-old game is a good reminder that modern software is not immune just because it’s new.
How leap year bugs affect everyday business operations
The incidents above are the visible failures. There are quieter ones that affect businesses more directly.
Certificates and document dates. Contracts, compliance certificates, invoices and insurance documents that carry automated date fields can produce invalid or incorrect dates on February 29. If your business generates any document with a calculated expiry or start date, check that the software vendor has tested this scenario for 2028.
Anniversary-based triggers. Employment contracts, subscription renewals, product warranties and invoice payment terms often rely on anniversary calculations. Software that adds 365 days to a date rather than incrementing the year will produce off-by-one errors during leap years. These can flow through to late fees, incorrect renewal notices and payroll discrepancies.
Payroll. A leap year can add an extra payday for employees paid weekly or fortnightly. In a standard year there are 52 weekly pay periods; in some leap years the calendar can produce 53. That affects gross pay calculations, salary deductions, payroll tax and superannuation figures for the year. Australian payroll software should handle this automatically, but it’s worth confirming with your provider before February 2028 arrives.
December 31. Leap year bugs don’t stop on February 29. Because the year has 366 days, December 31 becomes day 366. Applications hard-coded for 365 days can fail or miscalculate on the last day of a leap year. Watch for this in financial close processes, annual reporting and any system that runs year-end batch jobs.
IoT and connected systems carry extra risk
The Internet of Things (IoT) adds a layer of complexity that wasn’t present in earlier leap years. Connected devices, from smart meters and building management systems to security cameras and manufacturing equipment, often run embedded software that is rarely updated. Many of these systems are set-and-forget.
Unlike enterprise software, embedded firmware may not receive a patch before February 29, 2028. If your business relies on any connected devices for operational processes, access control or environmental monitoring, it’s worth asking your vendor when they last tested for leap year handling and whether a firmware update is planned before 2028.
In our experience working with Queensland businesses, IoT and building management systems are the category most likely to have been overlooked. They work quietly in the background, and leap year testing is rarely part of procurement conversations.
What to check before February 2028
You have time to act. Here is a practical starting point:
- List your date-sensitive systems. Payroll, HR, finance, document generation, CRM, contracts management, invoicing, scheduling, any IoT or operational technology. Anything that stores or calculates dates is a candidate.
- Ask your vendors directly. Has the software been tested against February 29, 2028? Is a patch or update planned? When was leap year handling last reviewed? Vendors who have a clear answer are lower risk. Vendors who can’t answer need a follow-up.
- Check your payroll configuration. Confirm your payroll system is set up to handle the potential extra pay period in a leap year. Review how superannuation and tax deductions are calculated if a 27th fortnight or 53rd week occurs.
- Review certificate and date-generation logic. If your business auto-generates dated documents, test a sample date of February 29, 2028 in your current system now. If it fails or produces March 1, raise it with your vendor immediately.
- Don’t forget December 31, 2028. Plan year-end processing and financial batch jobs with the awareness that December 31 will be the 366th day of the year, not the 365th.
A note on the year 2038 problem
While preparing for 2028, it’s worth being aware of a related date-handling issue on the horizon. Many systems built on Unix time store dates as a signed 32-bit integer counting seconds since January 1, 1970. That integer will overflow on January 19, 2038, causing systems to interpret the date as December 13, 1901. This is a separate problem from leap years, but it affects similar categories of software: older embedded systems, legacy databases and any infrastructure that hasn’t been updated to 64-bit date handling. If your IT systems are more than a decade old, the 2038 problem is worth adding to your technology review list alongside leap year readiness.
What we see at TTA: the vendor assumption trap
The most common mistake we see with leap year preparation is the assumption that vendors have already handled it. Some have. Enterprise platforms from well-resourced vendors usually patch known issues between leap years. Smaller or older software, including accounting add-ons, industry-specific tools, and older payroll systems, often go years without a leap year test because no one thinks to ask.
The 2024 Citrix and Sophos incidents show that even major security vendors can be caught out. Citrix confirmed its engineering team was working on a fix “so that users won’t have this problem during the next leap year, on February 29, 2028.” That’s a reasonable response, but it highlights that leap year readiness is not automatic even at the enterprise level.
Our recommendation: treat the vendor conversation as a standard part of your technology review in 2026 and 2027. Don’t wait until January 2028. By then, patch cycles will be tight and your options for switching platforms will be limited.
If you’re unsure where to start, a structured IT audit can map your date-sensitive systems and flag which vendors need to be questioned. It’s a straightforward exercise that gives you a clear picture before a deadline forces your hand.
Frequently asked questions
What is a leap year bug?
A leap year bug is a software error that occurs when code doesn’t correctly account for February 29 or the extra day in a 366-day year. The bug can cause crashes, incorrect date calculations, or silent data errors in payroll, certificates, billing, and other date-sensitive processes. It surfaces roughly every four years, when the next February 29 arrives.
When is the next leap year?
The next leap year is 2028. Leap day falls on Tuesday, 29 February 2028. That gives businesses just under two years from mid-2026 to identify date-sensitive systems, check vendor readiness, and confirm that payroll and document generation software is configured correctly.
Which types of business software are most at risk?
Payroll and HR systems, invoicing and billing platforms, document generation tools, scheduling software, and any IoT or embedded systems that store or calculate dates are at risk. Virtualisation software (as Citrix demonstrated in 2024) and security products (as Sophos demonstrated) can also be affected, even when they don’t appear to be date-dependent.
Does December 31 cause problems in a leap year?
Yes. In a leap year, December 31 is the 366th day of the year. Applications hard-coded to assume a year has 365 days can fail or produce incorrect results on that date. Year-end batch jobs, financial close processes, and annual reporting systems should be checked, not just February 29.
How can a small business prepare for the 2028 leap year?
Start by listing every system that handles dates, including payroll, contracts, certificates, billing, and any connected devices. Then ask each vendor directly whether the software has been tested for February 29, 2028, and whether a patch is planned. Raise concerns now, while there is time to change platforms or apply fixes before the date arrives.
Where to from here?
If you’d like a hand mapping your date-sensitive systems or want to know which of your platforms need a vendor conversation, get in touch with the TTA team. We work with businesses across South-East Queensland on exactly this kind of forward-looking IT review. Better to find the gaps now than on the morning of February 29, 2028.
