Twice a year, most of the Western world shifts its clocks by an hour. For most people, it's a minor inconvenience — a lost hour of sleep in spring, a gained hour in autumn. But for software systems, it's a recurring nightmare.

DST transitions create ambiguous and nonexistent times. When clocks spring forward, the hour between 2:00 and 3:00 AM simply doesn't exist. When clocks fall back, the hour between 1:00 and 2:00 AM happens twice. If your code doesn't handle these edge cases, things break — sometimes spectacularly.

Here are some of the most famous (and expensive) DST-related software failures.

🛒 The 2014 "Lost Hour" Shopping Glitch

In 2014, a major e-commerce platform experienced a strange bug: for exactly one hour, any order placed between 2:00 and 3:00 AM was rejected as "invalid date." The cause? The system was configured to reject timestamps that fell in a "nonexistent" hour — and during the spring DST transition, that hour genuinely didn't exist.

The company lost an estimated $50,000 in sales during that hour. The fix was simple — use UTC timestamps internally — but the lesson was expensive.

📅 The Google Calendar Bug

In 2016, Google Calendar had a bug where events scheduled between 2:00 and 3:00 AM on the DST transition day would appear at the wrong time — or disappear entirely. The issue was that the calendar was trying to normalize local times to a valid hour, and it was doing so incorrectly.

The bug affected users in multiple time zones and took several weeks to fully resolve. Google's fix involved a complete overhaul of how the calendar handled ambiguous times.

💹 The Financial Trading Glitch

Financial markets are particularly sensitive to time. In 2018, a major stock exchange experienced a DST-related glitch that caused trades to be timestamped incorrectly. Some trades appeared to happen before they were placed, which triggered regulatory red flags and caused a temporary halt in trading.

The root cause: the exchange's matching engine was using local time instead of UTC. During the DST transition, the local time jumped backward by an hour, making it appear that trades had occurred in the future.

The exchange lost millions in halted trading, and the incident prompted a industry-wide push toward UTC-only timestamps in financial systems.

🚂 The Amtrak Reservation System Bug

Amtrak's reservation system had a DST bug in 2019 that caused train schedules to display incorrectly for one day. Passengers who booked tickets for the morning of the DST transition saw departure times that were one hour off — some missed their trains as a result.

The bug was eventually fixed, but not before causing significant inconvenience and a flood of customer service complaints.

📱 The iPhone Alarm Bug

This one is legendary. In 2010, Apple's iPhone alarm clock failed to go off for many users on the day of the DST transition in Australia. The bug was caused by the alarm system not properly handling the shift from daylight saving time back to standard time.

Similar bugs have occurred in subsequent years in different countries. The issue is that recurring alarms — especially those set for "every day at 7 AM" — need to account for DST transitions. If they don't, they either fire an hour early or an hour late.

🧠 Why These Bugs Keep Happening

DST bugs are so common because they're a perfect storm of complexity:

• Ambiguous times: During the fall transition, 1:30 AM happens twice. Which one do you mean?
• Nonexistent times: During the spring transition, 2:30 AM doesn't exist. What do you do if a user tries to schedule something then?
• Inconsistent rules: Different countries observe DST at different times, and some don't observe it at all.
• Changing rules: Governments change DST rules frequently. The rules for 2026 might be different from the rules for 2025.
• Historical data: If you're working with old data, you need to know the DST rules that were in effect at that time.

The fundamental issue is that local time is ambiguous. A time like "2:30 AM on March 10" doesn't uniquely identify a moment — it could refer to two different moments (during the fall transition) or zero moments (during the spring transition).

✅ How to Avoid DST Bugs

The good news is that DST bugs are entirely preventable. Here's what you need to do:

1. Store all timestamps in UTC. This is the single most important rule. UTC has no DST transitions, so there's no ambiguity.
2. Use a time zone library. Don't try to handle DST rules yourself. Libraries like Luxon, date-fns-tz, or zoneinfo have the full IANA time zone database and handle edge cases correctly.
3. Be explicit about time zones. When a user schedules something, ask for the time zone. Don't assume it's their local time zone.
4. Handle ambiguous times gracefully. If a user schedules something during the fall transition, ask them which one they mean — or default to the first occurrence.
5. Handle nonexistent times gracefully. If a user schedules something during the spring transition, either reject it or shift it to the nearest valid time.
6. Test with edge cases. Write tests that specifically cover DST transitions in different time zones.
7. Keep your time zone database updated. The IANA database is updated several times a year. Make sure your system is using the latest version.

🌐 The Bigger Picture

DST bugs are a reminder that time is hard. It's not just a number on a clock — it's a complex system of conventions, politics, and history. Every time you convert between time zones, you're navigating a minefield of edge cases.

The developers who handle this well are the ones who respect the complexity. They don't assume that time is simple. They use the right tools, they test edge cases, and they store everything in UTC.

Do those things, and you'll avoid the fate of the companies above — whose DST bugs became cautionary tales for the rest of us.

Want to see how DST affects your schedule? Our Time Zone Converter Hub automatically handles DST transitions — so you don't have to.