Timezone Edge Case Generator

What this generator does

Produces timestamps and offsets chosen because they are awkward. The site's existing timezone tool hands you a valid IANA identifier, which is the right answer when a test needs a plausible zone string; this answers the other question, which is when that zone will catch you out. Each case is re-derived from its own date before it is shown, so a case filed as a clock change that does not fall on that rule's Sunday cannot reach the page.

How to use this tool

1. Choose the range of years the transition dates should come from.
2. Tick the kinds of case you want — the clock changes, the odd offsets, or all of them.
3. Generate, then copy the set as CSV straight into a fixture file.
4. Add a seed if you want the identical set back in CI.

Understanding the controls

From and to year

Which years the transition dates are calculated for. Worth knowing: only the clock-change cases vary by year. The fractional offsets and the never-changing zones are properties of a place, not a date, so widening the range does not produce more of them — and the tool says so rather than silently repeating.

How many cases

An upper limit, not a promise. If you ask for fifty cases of a kind that only has two, you get two and an explanation.

Which kinds

Nine kinds, and they test different things. The clock changes catch duration arithmetic; the skipped and repeated local times catch parsing and storage; the fractional offsets catch anything that stores an offset as a whole number of hours; the date-line pair catches reporting.

Seed

Any word makes the draw reproducible. Leave it empty and the browser's cryptographic generator is used instead, which is the right choice when you want a different set each time you look.

Common use cases

• Building a fixture file before touching anything that stores or compares timestamps
• Writing the regression test after a booking landed an hour out twice a year
• Checking that a scheduled job does not run twice on the day the clocks go back
• Proving a report grouped by day says whose day it means
• Showing a team why storing local time without an offset loses information

How this generator works

Transition dates are computed from the rules in force today rather than looked up: the EU and UK change on the last Sunday of March and October, the United States on the second Sunday of March and the first Sunday of November, and the southern-hemisphere examples on the first Sundays of October and April. The nth-weekday arithmetic is done in UTC so the machine you are sitting at cannot change the answer. Every generated case then goes through a checker that recomputes the expected date for its own rule and year and compares; the half-hour and 45-minute offsets are checked to actually end in :30 and :45.

Randomness and fairness

Which cases you get is random; what each case means is not. Without a seed the draw uses the browser's cryptographically secure generator. With a seed it uses a small deterministic generator instead, which is reproducible and therefore explicitly not cryptographically secure — that is the point of a seed, but never use a seeded draw where unpredictability matters. The set is drawn without replacement, so no case appears twice in one run.

For how randomness is produced across the whole site, see how Generate Random works.

Assumptions this tool makes

• The current EU, UK, US and Australian daylight-saving rules are in force.
• Arithmetic is done in UTC, so the machine you are sitting at cannot change the answer.
• Southern-hemisphere cases use the Australian pattern as a representative; other southern countries differ.

Limitations and good to know

• These are the daylight-saving rules as they stand today. They have changed before — the United States moved its dates in 2007 — and the EU has voted to abolish the changeover without yet doing it.
• There is no IANA time zone database here. For dates far in the past or future, that database is the only authority; this computes from published rules instead.
• Offsets before about 1970 are not modelled. Many places had rules then that no library agrees on now.
• The zone lists are representative, not exhaustive. There are more than 350 IANA zones and this names a few dozen of the awkward ones.
• It gives the day a clock change falls on, not the exact instant the offset moves.

Common mistakes

Testing with a zone name instead of a moment

Setting the test timezone to Europe/London proves very little on 14 July. The bug lives on the last Sunday in March, which is why this tool gives you dates rather than names.

Assuming a day is 24 hours

Two days a year it is not. Adding 86,400 seconds to get 'tomorrow at the same time' is wrong on both of them, in opposite directions.

Storing local time without an offset

On the day the clocks go back, one local hour happens twice, and a timestamp without an offset genuinely cannot say which. The information is gone, not merely hidden.

Treating offsets as whole hours

India is +05:30, Nepal is +05:45 and the Chatham Islands are +12:45. An integer hour field silently loses the remainder for hundreds of millions of people.

Practical tips

• Commit the seeded set rather than the generated file, so the fixtures can be regenerated and reviewed as a diff.
• Run the skipped-local-time case through your parser first — a parser that silently accepts a time that does not exist will hide every other bug on this list.
• Pair this with the date edge case generator: between them they cover the calendar and the clock, which fail in different ways.

Privacy and your data

Everything is generated in your browser from the years you type in. No timestamps, seeds or generated fixtures are sent anywhere, and nothing is stored between visits.

Frequently asked questions

Why do I get fewer cases than I asked for?

Because several kinds do not vary by year. There are only two 45-minute offsets in the world, so asking for fifty of them across twenty years still yields two. The tool says which kinds ran out rather than padding the list with repeats.

Are these real transition dates?

They are computed from the published rules, and every one is checked to fall on the correct Sunday before you see it. For dates far outside the next decade or two, verify against the IANA database — the rules are politically changeable and have changed before.

Why is there both this and the timezone test value generator?

They answer different questions. That one gives you a valid zone identifier when a field needs one. This one gives you the moments at which a zone behaves awkwardly, which is what a test suite actually needs.