Time Zone Converter
Convert times across world time zones instantly.
How to use
- Pick the "source time zone" that the time belongs to: your device's zone is selected by default.
- Choose a date and time, or press "Now" to use the current moment.
- Tick the target city zones you want to compare (any number), and results appear row by row in the order shown.
- Each row shows that zone's date, time and weekday plus its UTC offset; daylight saving is handled automatically by the browser's Intl engine: no manual adjustments needed.
- Changing the zone, time or checkboxes re-converts instantly, so you can line up every city for a cross-time-zone meeting in one view.
FAQ
Do I need to handle daylight saving time myself?
Which time zone is the input interpreted in?
How complete is the zone list?
Why do two cities show the same offset?
How to use
- Confirm the source zone
Pick the zone your time belongs to in the source dropdown; your device zone is preselected. The list comes from the browser IANA database, covering hundreds of zones.
- Enter the date and time
Type the moment into the date-time field or press Now to load the current time. Input is read as local wall time in the source zone, not UTC.
- Tick the target cities
Check any cities you want to compare, such as Shanghai, New York, London and Tokyo. Press Convert to build the side-by-side result rows.
- Read offsets and weekdays
Each row shows the local date, time, weekday and UTC offset. Watch the date column: cities across the international date line may already be a day ahead or behind.
- Adjust to find a slot
Editing the time or toggling cities re-converts instantly. Nudge the moment step by step until every city falls inside reasonable working hours.
About this tool
World time zones are offsets from UTC plus local daylight-saving rules. New York runs UTC-5 in winter but UTC-4 during DST. This tool converts through the IANA time-zone database built into your browser. Every result applies the rules in force at that moment, with no manual hour-shifting. The entered time is read as local wall time in the source zone, then mapped onto every checked city. All rows describe one true instant.
The classic use case is scheduling cross-time-zone meetings. Enter the candidate time and tick New York, London, Tokyo and the rest. You can see at a glance who would be up in the middle of the night, then nudge until everyone lands in working hours. Remote teams checking deadlines, students calling family abroad and sellers timing store launches all benefit. Results recalculate instantly on every change, so a globally agreeable schedule takes minutes.
How it works
Zone names in Area/City form come from the IANA time-zone database, which stores not just offsets but the full rule history of every zone. Asia/Shanghai covers the whole country and has sat at a steady UTC+8 with no daylight saving since 1991. Earlier decades that did observe DST still back-calculate correctly. Offsets are not all whole hours either: India runs UTC+5:30, Nepal UTC+5:45 and South Australia UTC+9:30 in standard time. South Australia adds one more hour while its daylight saving is in force. The tool applies whatever rule was in effect at the entered moment, so no manual hour-shifting is needed.
Recurring meetings hide a subtle trap. One pinned to a city's local wall time drifts by an hour relative to everyone else after each DST transition. Stable series should anchor the instant in UTC, or be re-checked before every occurrence. Anchoring in UTC costs every participant one conversion, and in return the schedule never drifts with anyone's daylight saving. Transition days add another wrinkle: during the US spring-forward, the local time 2:30 AM simply does not exist. When an input lands on a transition minute, give its date and offset rows a manual look, or move to a nearby date.
When to use it
- Finding overlap for a global standup
Tick rows for San Francisco, London and Shanghai, then walk the candidate time through the day. Who is asleep and who is heading home is visible at a glance. A tolerable slot usually settles within minutes of nudging.
- Translating a maintenance window
The announcement says UTC 22:00 for two hours. Checking your own zone turns that into a local midnight or a workday afternoon. That decides whether you watch the logs live or hand the window to whoever is on call.
- Aligning a global launch moment
Product launches and game server openings must fire at one worldwide instant. Fix the moment in UTC and verify each continent's local readout, so the local times quoted in your announcement copy stay honest in every region.
Tips & tricks
- Shanghai and Singapore are both UTC+8, so identical rows are expected. That is not a conversion bug.
- When scheduling across continents, cover the most distant zone first, then accommodate the closer colleagues.
- Around the March and November DST switch dates, the results are already correct. No manual compensation is required.
Things to watch
- Half- and quarter-hour offsets exist
India runs UTC+5:30, Nepal UTC+5:45 and South Australia UTC+9:30 in standard time, so mental arithmetic in whole hours fails quietly. Read the UTC offset printed on each result row instead of counting hours in your head.
- Transition days create gaps and overlaps
During spring-forward some local times never occur; during fall-back the same wall time happens twice. When your input lands on a transition minute, compare the row's date and offset to see exactly how the moment was resolved.
- Recurring meetings drift with DST
A standing Tuesday-10AM-in-New-York meeting shifts an hour relative to Beijing every March and November. For anything repeating across a DST boundary, re-convert the schedule before each confirmation cycle and resend the invite.