Why does a target sometimes show "(next day)" or "(prev day)"?

A 10:00 New York meeting is 00:00 the next day in Tokyo — same instant, different calendar date. The (next day) / (prev day) badge alerts you when the date rolls so you don’t double-book yourself on what looks like a different day.

What counts as "workday hours"?

Monday through Friday, 09:00 to 18:00 local time. The flag is informational — workday norms vary by industry, country (Sunday is the weekday-start in much of the Gulf), and individual schedule. Use it as a sanity check, not a hard rule.

Can I add an arbitrary IANA zone?

Yes — type any IANA zone string (e.g. Pacific/Honolulu, Africa/Johannesburg, America/St_Johns including the awkward 30-min offset). The full tz database is supported wherever the browser supports Intl.DateTimeFormat — i.e. all modern browsers.

Why is the same time showing two different wall-clocks for the same target?

Almost certainly DST. If you toggle the meeting date across a DST boundary, the wall-clock for a non-changing target zone is constant but the SOURCE-zone offset changes — so the same source wall-clock maps to a different instant, which shows up differently in the target. Pick the meeting date carefully.

Why does a target sometimes show "(next day)" or "(prev day)"?

A 10:00 New York meeting is 00:00 the next day in Tokyo — same instant, different calendar date. The (next day) / (prev day) badge alerts you when the date rolls so you don’t double-book yourself on what looks like a different day.

What counts as "workday hours"?

Monday through Friday, 09:00 to 18:00 local time. The flag is informational — workday norms vary by industry, country (Sunday is the weekday-start in much of the Gulf), and individual schedule. Use it as a sanity check, not a hard rule.

Can I add an arbitrary IANA zone?

Yes — type any IANA zone string (e.g. Pacific/Honolulu, Africa/Johannesburg, America/St_Johns including the awkward 30-min offset). The full tz database is supported wherever the browser supports Intl.DateTimeFormat — i.e. all modern browsers.

Why is the same time showing two different wall-clocks for the same target?

Almost certainly DST. If you toggle the meeting date across a DST boundary, the wall-clock for a non-changing target zone is constant but the SOURCE-zone offset changes — so the same source wall-clock maps to a different instant, which shows up differently in the target. Pick the meeting date carefully.

Time Zone Meeting Planner

Pick a meeting time in one time zone and see what it looks like everywhere else. DST-aware via Intl.DateTimeFormat. Workday-hours flagged per zone.

Result

Meeting

—

Enter a valid date (YYYY-MM-DD) and time.

How to use this calculator

Pick the date and time in the SOURCE time zone (the zone the time is naturally stated in).
Edit the comma-separated list of target zones — full IANA strings work (Asia/Tokyo, America/Mexico_City, Pacific/Auckland …).
Read the per-zone result rows; a ✓ flags zones where the time falls in normal workday hours.
If a zone shows "invalid TZ", check the spelling — IANA names are case-sensitive and use underscores (Los_Angeles, not Los Angeles).

About this calculator

Scheduling a meeting across time zones is a fast way to embarrass yourself by an hour. This planner takes one wall-clock time in a source zone and renders the same instant in every other zone you list — DST-aware, because it uses the IANA tz database via the browser’s Intl.DateTimeFormat. Each row also tells you whether the proposed time lands inside that zone’s normal 9-to-18 workday or is going to drag someone out of bed. Use it before you send the invite; sanity-check it after the next round of clock changes.

How it works — the formula

instant = source_local − offset_at_source_local(zone)
local_in_tz(instant, zone) = Intl.DateTimeFormat({ timeZone: zone })

Time-zone conversion is not a fixed offset because of DST and historical zone changes. The IANA tz database encodes every transition for every zone, and modern browsers expose it through Intl.DateTimeFormat. The trick here is finding the right UTC instant for a stated local time: build a naïve UTC, ask Intl what it looks like in the source zone, then back-out the offset.

Sources: IANA Time Zone Database (tz/tzdata) · ECMA-402 — Internationalization API (Intl.DateTimeFormat) §13 · Olson tz reference — theory.html

Worked examples

Example 1

10:00 New York on a non-DST date

Inputs:: date=2026-01-15, time=10:00, sourceTz=America/New_York
Output:: London 15:00, Tokyo 00:00 (next day)

Example 2

Same time during US DST

Inputs:: date=2026-06-15, time=10:00, sourceTz=America/New_York
Output:: London 15:00 (BST), Berlin 16:00 (CEST)

Example 3

Cross-day flag

Inputs:: date=2026-06-15, time=22:00, sourceTz=America/New_York
Output:: Tokyo 11:00 (next day)

Limitations

Future DST is assumed to follow current legislation; rule changes (e.g. EU permanent-DST proposal, US Sunshine Protection Act, Mexico 2022 abolition) are not predictable.
The workday flag is a fixed Mon-Fri 09:00-18:00 heuristic; cultural and individual norms vary.
No support for pre-1970 dates — IANA tzdata covers post-1970 transitions reliably; older dates use modern offsets.

Frequently asked

Yes. The conversion uses Intl.DateTimeFormat under the hood, which delegates to the browser’s IANA tz database. So 10:00 New York on a March date that falls after the US spring-forward gets the right UTC instant; 10:00 New York on a date BEFORE the switch also gets the right instant. The system handles the switchover automatically.