Time Zone Bugs: How to Test Your App Across the World

A meeting appears an hour early for half your users. A daily report runs twice on one Sunday a year. A user in India sees a timestamp that is thirty minutes wrong. Time zone bugs are rarely spotted on a developer’s laptop because the developer lives in one zone. The cure is testing against a varied set of zones on purpose. Here is what makes time zones tricky and how to build a test matrix that catches problems.

Offsets are not always whole hours

It is tempting to assume time zones differ in whole hours. Real offsets break that assumption:

• Asia/Kolkata — UTC+05:30 all year.
• Asia/Kathmandu — UTC+05:45.
• Pacific/Chatham — UTC+12:45 in standard time.
• Pacific/Kiritimati — UTC+14:00, one of the earliest places to start each new day.
• Australia/Lord_Howe — shifts by only 30 minutes for daylight saving.

Any code that stores offsets as integers of hours, or rounds them, will fail in these places.

Daylight saving creates missing and repeated times

When clocks spring forward, a local time such as 02:30 may simply not exist that night. When they fall back, an hour happens twice, so 01:30 can refer to two different moments. Scheduled jobs, alarms and “every day at 2:30” rules need a clear policy for both cases.

Dates of change also differ: the United States, the European Union and the Southern Hemisphere switch on different dates, and many countries do not use daylight saving at all. Rules change by law from time to time, which is why software relies on the regularly updated IANA time zone database.

Rules that prevent most bugs

1. Store moments in UTC. Convert to local time only when displaying.
2. Store the zone name, not the offset. Europe/Lisbon knows its daylight saving rules; “+01:00” does not.
3. Keep future local events as local time plus zone. If a country changes its rules, a meeting at 9:00 local should stay at 9:00 local.
4. Use your platform’s time zone library. Never write offset arithmetic by hand.
5. Keep the tz data updated on servers and in dependencies.

Build a test matrix with RandNow

The Random Time Zone Generator above gives you a varied set of zones quickly:

1. Set How many? anywhere from 1 to 50.
2. Press Generate. Each zone appears in Region/City format with its current UTC offset and local time, for example Asia/Dhaka (UTC+06:00 · now 10:18 PM).
3. Export the list as CSV, JSON or TXT and use it to parameterize your tests.
4. Run your scheduling, display and reporting tests once per zone.

The local times are calculated from your device’s clock at the moment you generate, so the list also works as a quick world-clock snapshot. Add a few fixed edge cases by hand — a half-hour zone, a 45-minute zone and one Southern Hemisphere zone — so they are always covered.

A starter checklist

• Display a timestamp created at 23:30 UTC — does the date shift correctly east and west?
• Schedule an event during a daylight saving gap and an overlap.
• Run a daily report across the night the clocks change.
• Check a “today” filter for a user in UTC+14 and one in UTC−10.
• Confirm exported dates use ISO 8601 with an offset or a trailing Z.

Time zones in the interface

Users rarely know their zone’s official name. Let them pick a familiar city, detect a sensible default from the device, and show the time in their zone next to any event created by someone elsewhere. Writing “9:00 (Lisbon time)” prevents more confusion than any amount of backend logic.

Random times of day help fill these cases:

Pro tips

• Run your test suite with the server set to a non-UTC zone at least once.
• Include Asia/Kolkata and Asia/Kathmandu in every time zone test set.
• Log timestamps in UTC with an explicit Z so logs from different servers line up.
• Never assume a day has exactly 24 hours in local time.

Frequently asked questions