Date & Time Test Simulator

Runs in browser New Test Design

A planner for date and time simulation testing. Describe a time-dependent rule — a trial that expires 30 days after sign-up, an offer that closes at 23:59 Riyadh time, a monthly renewal, an age limit, a job that runs every day at 02:30 — and the zone it runs in. The simulator lists the moments to freeze the clock at (one second before, at and after the boundary, every daylight-saving change in range, the 2038 limit and, for expiry and renewal rules, month ends, 29 February and the new year), the expected state at each, and a fake-clock snippet for Playwright, Jest, Vitest, Java, Python, .NET or libfaketime. Everything is calculated in your browser with its time-zone data.

Privacy: This tool runs entirely in your browser. Your input never leaves your device.

What is date and time testing?

Date and time testing checks behaviour that depends on the clock — expiry, renewals, schedules, age limits, reports — at the moments that matter: just before, exactly at and just after each boundary, at month and year ends, on 29 February, on daylight-saving change days and in several time zones. Because nobody can wait 30 days for a test, the clock is made controllable (an injected or faked clock, a time-travel setting) or the dates in the test data are shifted so the relationships between them stay valid.

Read the guide: Date and Time Testing

How to use Date & Time Test Simulator

  1. Choose the rule to test, for example "Expires after a duration" for a 30-day trial.
  2. Enter the start as it appears on the wall clock in the rule's zone (2026-01-31 10:00) and choose the zone, such as Asia/Riyadh.
  3. Set the amount and unit, and whether the rule still counts as valid at the exact boundary second.
  4. Pick a second zone to compare (often UTC, where servers store time) and how many months to look ahead for daylight-saving changes.
  5. Read the moments table: freeze your application's clock at each moment with the snippet and check that it shows the expected state.

Date & Time Test Simulator features

  • Five rule types: expiry after a duration, fixed deadline, recurring renewal, age threshold and daily scheduled job
  • Lists the clock moments to test — for expiry and deadline rules one second before, at and after the boundary — with the expected state at each
  • Finds every daylight-saving change in the look-ahead period for the chosen IANA zone, to the second, and flags run times that fall in a gap or happen twice
  • For an expiry in months or years, shows month-end clamping (31 January + 1 month) next to what JavaScript's Date#setMonth would give; for renewals, the drift of dates computed from the previous renewal
  • Compares the boundary with a second zone (your server's UTC, or another user's) and flags a calendar-day change
  • Prints a fake-clock snippet for Playwright, Jest, Vitest, Java, Python (freezegun), .NET (FakeTimeProvider) or libfaketime, and exports the moments as CSV

Date & Time Test Simulator example

A 30-day trial that starts on 31 January in Riyadh

Input:

Rule: Expires after a duration · Start: 2026-01-31 10:00 · Zone: Asia/Riyadh · 30 days · At the boundary: already expired · Second zone: UTC

Output:

Expires at 2026-03-02T10:00:00+03:00 (2026-03-02T07:00:00Z, epoch 1772434800) · Elapsed hours 720
Moments: 2026-03-02T09:59:59+03:00 → Valid · 2026-03-02T10:00:00+03:00 → Expired · 2026-03-02T10:00:01+03:00 → Expired · end of 2 March → Expired (a date-only "valid until 2 March" would mislead), plus the two month ends and the new year
Warnings: Asia/Riyadh has no daylight-saving change — also test a zone that has one

When to use Date & Time Test Simulator

  • Writing the test cases for trials, coupons, password-reset links, token lifetimes and subscription renewals before the feature ships
  • Checking a scheduled job, report or reminder that runs at a local time around a daylight-saving change
  • Reviewing an age gate (18+) including people born on 29 February
  • Explaining to a developer why a 23:59 Riyadh deadline closed three hours late: the same wall-clock time was read as UTC

Frequently asked questions about Date & Time Test Simulator

What is date and time simulation testing?

It is testing time-dependent behaviour by controlling the clock the software reads — freezing or shifting it to chosen moments — instead of waiting for the real date. This tool tells you which moments to choose for a rule and what the software must do at each one.

Does the simulator change the clock of my application?

No. It calculates the moments and expected results, and gives you a snippet to freeze the clock in your own test framework (Playwright, Jest, Vitest, Java Clock, freezegun, .NET FakeTimeProvider or libfaketime). Your application and system clock are untouched.

Why does adding one month to 31 January give 28 February?

Most date libraries clamp to the last day of a shorter month, as java.time and this tool do. JavaScript's Date#setMonth does not: it overflows and lands in March. The simulator warns you when the two differ, because a test should pin down which one the product uses.

Which daylight-saving changes does it find?

Every change of the zone's UTC offset between the start and the look-ahead horizon, found from your browser's IANA time-zone data and located to the second. Zones without daylight saving time, such as Asia/Riyadh, show none, and the tool suggests testing a zone that has them as well.

Is anything sent to a server?

No. The calculation runs entirely in your browser; nothing you type is uploaded or stored.

Technical notes

Wall-clock times are converted to instants with the browser's Intl time-zone data (the IANA tz database the browser ships). A time that does not exist in the zone — inside a spring-forward gap — is moved forward, and an ambiguous one in a fall-back overlap takes the earlier instant; both cases are reported. Daylight-saving changes are found by sampling the zone's UTC offset every six hours and bisecting each change to the second.

Calendar units are added in the rule's zone: days keep the wall-clock time across a daylight-saving change (so 30 days may be 719 or 721 hours, which the tool reports), and months and years clamp to the last day of a shorter month, as java.time's plusMonths does. Minutes and hours are exact elapsed time.

Limitations and methodology

The tool plans the tests and states the expected result for the rule you describe; it does not change your application's clock or run your tests.

Time-zone rules come from your browser's tz data. Your servers and devices may run a different tz version, so a recently changed zone can behave differently there — test with the tz data you deploy.

Leap seconds are not modelled, because Unix time and most systems ignore them.

Business rules such as "valid until the end of the expiry day" or the birthday of someone born on 29 February are choices; the tool shows the alternatives, it does not decide them.

References

  • Time Zone DatabaseIANAThe tz database of the world's time zones and their historical offset and daylight-saving rules, updated several times a year.
  • RFC 3339: Date and Time on the Internet: TimestampsIETF · 2002The Internet timestamp profile of ISO 8601 (2026-09-23T10:15:00Z) and its offset rules.
  • Clock — PlaywrightMicrosoft (Playwright)How Playwright controls time in the browser under test: page.clock with install, setFixedTime, setSystemTime, fastForward, runFor and pauseAt, and the time APIs it overrides.