Timezone and DST bugs to hunt every release

A customer in Sydney creates a task at 23:30 on 31 March. Her manager in Los Angeles opens the same task and sees it dated 30 March. Nobody is lying, and no data is corrupted. The app just stored one moment and showed it two different ways.

These bugs are cheap to find and expensive to fix later. Good timezone testing takes about twenty minutes, and this guide gives you the exact dates and timezones to use.

Short version

• Test the last 30 minutes of a day, not the middle of the afternoon.
• Test the two broken hours: the one that never happens and the one that happens twice.
• Check date-only fields separately from date-and-time fields. They follow different rules.
• Compare a report total against the dashboard it claims to summarise.
• Keep a fixed list of test timezones and reuse it every release.

---

Two terms you need first

UTC is Coordinated Universal Time. It is one worldwide clock with no daylight saving. Most systems store times in UTC and convert to your local time only when they show it on screen.

DST is daylight saving time. Some countries move their clocks forward one hour in spring and back one hour in autumn. When they do, one hour disappears from the calendar and, six months later, one hour happens twice.

Almost every timezone bug is a mistake at one of those two conversions.

Midnight boundaries

A day boundary is the moment where the date changes. Anything grouped by day breaks there.

Try these on https://staging.example.com with two accounts: [email protected] set to Australia/Sydney and [email protected] set to America/Los_Angeles.

1. Create a task due 2026-03-31 at 23:30 Sydney time. Open it as the Los Angeles user. The due date should still read 31 March if the field is a date, and should read a converted local time if the field is a date and time. It should never read both.
2. Set a filter to "Today" at 00:15 local time. Check that items created twenty minutes ago still appear.
3. Open an activity feed grouped by day. Items created at 23:55 and 00:05 must not land in the same group for one user and different groups for another.
4. Set a reminder for 00:00. Confirm it fires once, on the right day.

Date-only fields deserve their own pass. A birthday, an invoice date, and a public holiday are not moments in time. They are labels. If your app stores 1990-05-14 as 1990-05-14T00:00:00Z and shows it to a user in UTC-10, the birthday becomes 13 May. The rule is simple: a date-only value should look identical in every timezone.

The hour that does not exist

On 2026-03-08 in America/New_York, clocks jump from 01:59 straight to 03:00. The time 02:30 does not exist that day.

Ask the app to use it anyway.

1. Schedule a recurring meeting for 02:30 every day, starting 2026-03-06. Look at what it does on 8 March. It should move to 01:30 or 03:00, and it must not disappear or throw an error.
2. Type 2026-03-08 02:30 into any date picker that allows manual entry. A common failure is RangeError: Invalid time value in the console, followed by a blank screen.
3. Check any nightly job scheduled between 02:00 and 03:00. In the spring, it can skip a day. Confirm with the team where that job runs and in which timezone.

The hour that happens twice

On 2026-11-01 in America/New_York, clocks go back from 02:00 to 01:00. The time 01:30 happens twice, once at UTC-4 and once at UTC-5.

1. Create two records at 01:30, one before the change and one after. Sort the list by time. The second record must appear after the first, not before it.
2. Look at a report for that day. It has 25 hours. A chart with a fixed 24-bar layout will drop or double a bar.
3. Run any job that says "every hour". It should run 25 times, not 23 and not 26.

Ambiguous times are also a good place to find duplicate-detection bugs. If your app blocks two bookings at the same time, book 01:30 twice on 1 November and see whether it wrongly reports a clash.

UTC drift in reports

This is the bug that reaches finance. A report is bucketed in UTC, but the person reading it lives in UTC+10.

Say a team in Brisbane sells 40 items on Monday. Brisbane is ten hours ahead of UTC, so the 10 sales made before 10:00 on Monday morning are still Sunday in UTC. The daily report shows 30 for Monday and 10 for Sunday. The dashboard, which uses local time, shows 40. Both are "correct" and they disagree.

Test it directly:

1. Create records at 09:00, 13:00, and 23:45 local time on the same local day.
2. Open the daily report and the dashboard side by side. The totals must match.
3. Export the same data as CSV. Check that the date column matches what you saw on screen.
4. Change the month boundary too. Create a record at 23:50 on 2026-07-31 and confirm it lands in July on every screen.

If the report is deliberately in UTC, that is a valid choice. It just has to say so on the page. A label like "All times UTC" turns a bug into a documented behaviour.

How to actually run these tests

You do not need a virtual machine. Four methods cover most of it.

1. Change your operating system timezone. On macOS this is System Settings, then General, then Date and Time. On Windows it is Settings, then Time and Language. Restart the browser afterwards, because some pages read the timezone only once at load.
2. Use Chrome DevTools. Open DevTools, press Escape, open the three-dot menu, choose "Sensors", and set a location. Location controls the timezone the page sees. This is faster than changing your machine, but it does not affect the server.
3. Set the timezone on the test account itself, in the app's profile settings. This finds bugs where the app trusts the profile in one place and the browser in another. That mismatch is common and worth hunting on purpose.
4. Use a second incognito window for the second user, so both sessions stay signed in at once.

Always record which method you used. A developer cannot reproduce "the date was wrong" without knowing whether your browser or your profile was set to Sydney. If you file the bug with Crosscheck, the browser timezone, locale, and console errors are captured with the report, so that question does not come back to you a day later.

Test timezones and dates to keep on file

Pick timezones that break naive code, not just the popular ones.

Australia is worth its own row because the seasons are flipped. A team that only tests US DST will ship a bug that lands in April for half its customers.

A short pass you can run every release

If you have twenty minutes, do this and nothing else.

1. Set your profile to Asia/Kolkata. Create one record at 23:50 local time.
2. Switch to America/Los_Angeles. Confirm the record still shows the date you expect and check the console for errors.
3. Open the daily report and the dashboard. Compare the totals.
4. Set a recurring event for 02:30 on 2026-03-06 and look at 8 March.
5. Check one date-only field, such as an invoice date, in both timezones.

That covers midnight, DST, UTC drift, and date-only handling. Most releases pass. The ones that fail usually fail loudly, which is exactly what you want before the code reaches a customer.

Frequently asked questions

Do I need to test timezones if all our users are in one country? Yes, if that country uses daylight saving. DST bugs happen inside a single timezone. A country like India has one offset and no DST, which removes most of the risk but not the date-only field problem.

Should times be stored in UTC or local time? Store moments in UTC and convert on display. Store date-only values, such as a birthday or an invoice date, as a plain date with no time and no timezone attached.

How do I test a timezone without changing my computer settings? Use the Sensors panel in Chrome DevTools to set a location, which changes the timezone the page sees. Remember that this only affects the browser, so server-side reports will still use their own setting.

Why do reports and dashboards show different totals? Usually one groups by UTC day and the other groups by the user's local day. Both are defensible, but they must agree, and the page should say which one it uses.

Which single test finds the most timezone bugs? Create a record at 23:50 local time, then view it from a timezone at least ten hours away. It exposes date shifting, grouping, and filtering in one step.