Time Zone Test Data Generator

Generate DST transitions, leap days, month-end, year-boundary, and invalid-date test cases for any IANA timezone and year.

Runs 100% client-side
Copy outputCSV & Markdown export
On this page4 sections

Selected: Europe/London

2026 is not a leap year — Feb 29 does not exist

Categories

HOW TO USE

  1. 01Pick a timezone and year, and choose which edge cases to generate (DST, leap year, boundaries, invalid dates).
  2. 02Click Generate to produce the timestamps in ISO 8601, Unix ms, local time, and UTC.
  3. 03Copy the table or export it for use as test inputs.

Try it

Europe/London, 2024 → generate the DST spring-forward and fall-back timestamps

WHEN TO USE

Use when building test cases for features that process dates, times, or scheduled events. Generates the edge-case timestamps that most testers miss: DST spring-forward/fall-back transitions, Feb 29 in leap vs non-leap years, end-of-month boundaries, year rollovers, and intentionally invalid dates — all rendered in ISO 8601, Unix ms, local time, and UTC.

WHAT BUGS THIS FINDS

  • DST gap bug

    Timestamps in the spring-forward gap (e.g. 2:30 AM when clocks jump to 3 AM) are silently accepted or incorrectly stored as an hour earlier/later.

  • Leap-year off-by-one

    Date validator uses year % 4 === 0 without the century exception, accepting Feb 29 2100 as valid (2100 is not a leap year).

  • UTC offset applied twice

    A stored UTC timestamp is converted to local time for display and then stored again with the offset already applied — accumulates error on repeated saves.

  • Year-boundary shift

    An event scheduled for Dec 31 23:00 UTC is displayed as Jan 1 in a UTC+2 timezone — reports show it under the wrong year.

QA USE CASES

01

Test DST transitions

Generate the exact spring-forward and fall-back timestamps for a timezone to confirm the application handles the 1-hour gap/overlap correctly.

02

Verify leap-year logic

Confirm the system accepts Feb 29 in 2024 and rejects it in 2023 — a common fence-post bug in date validators.

03

Test year/month-end boundaries

Generate Dec 31 23:59:59 and Jan 1 00:00:00 in multiple zones to catch timezone-offset bugs that shift events across day/month/year boundaries.

04

Build invalid-date negative tests

Generate Feb 30, Apr 31, month 13 and similar structurally invalid dates to confirm the system returns the correct error.