🌐 World Clock & Global Timezone Converter
A world clock converter across 12 major cities, with offsets shown to the minute because not every zone is a whole hour and DST dates do not align.
Leave blank to track the current time live.
Reading your clock…
Offsets come from your browser’s IANA timezone database, so daylight saving is handled for the date you are converting rather than for today — which matters, because the northern and southern hemispheres change clocks at opposite times of year and a meeting six months out may not be the gap you expect. India, Iran and parts of Australia sit on half-hour or 45-minute offsets, and Nepal on 45 minutes, which is why the offsets here are shown to the minute.
What World Clock & Global Timezone Converter Does
A timezone is not an offset. It is a set of rules — an offset plus a history of when that offset changed and a schedule for when it will change again — and treating it as a fixed number is where most scheduling mistakes begin.
The practical consequence is that "New York is five hours behind London" is true for part of the year and wrong for the rest. Both observe daylight saving, but they switch on different dates, so for two weeks in March and one in autumn the gap is four hours instead of five. Convert a specific date rather than assuming a constant.
The southern hemisphere makes it worse, because its clocks move the opposite way. The gap between London and Sydney swings between nine, ten and eleven hours across the year. A recurring meeting set once will drift out of everyone's working day twice a year unless it is anchored to a timezone rather than a time.
Not every offset is a whole hour, either. India is UTC+5:30, Iran +3:30, Nepal +5:45, and parts of Australia +8:45 — which is why offsets here are shown to the minute rather than rounded.
How to Use World Clock & Global Timezone Converter
- Check your current local time at the top banner
- Scan the 12 world capital clock cards for current time, day of the week, and date differences
Formula Used by World Clock & Global Timezone Converter
What determines a local time
local time = UTC + base offset + daylight saving offset on that date
- IANA identifier
- Region/City, such as Europe/London — the timezone including its whole rule history
- abbreviation
- GMT, BST, EST — ambiguous and not unique; CST alone means at least three different things
- fixed offset
- UTC+5:30 — a number with no rules attached, correct only at one instant
Worked example
A meeting at 15:00 London time.
- In January, London is UTC+0 and New York UTC−5 — the meeting is at 10:00 there
- In July, London is UTC+1 and New York UTC−4 — still 10:00
- On 15 March, the US has changed and the UK has not — the meeting is at 11:00
Result: Same nominal times, different real gap, because the two regions switch on different dates.
Offsets that are not whole hours
A common source of bugs in software that stores offsets as integers.
| Place | Offset |
|---|---|
| India, Sri Lanka | UTC+5:30 |
| Nepal | UTC+5:45 |
| Iran | UTC+3:30 |
| Afghanistan | UTC+4:30 |
| Myanmar, Cocos Islands | UTC+6:30 |
| Chatham Islands | UTC+12:45 |
| Newfoundland | UTC−3:30 |
| Eucla, Australia | UTC+8:45 |
Why abbreviations are unsafe
Use IANA identifiers in anything that has to be correct.
| Abbreviation | Could mean |
|---|---|
| CST | US Central (−6), China Standard (+8), or Cuba Standard (−5) |
| IST | India (+5:30), Ireland (+1), or Israel (+2) |
| BST | British Summer (+1) or Bangladesh Standard (+6) |
| AMT | Amazon (−4) or Armenia (+4) |
How to Read Your Result
Store the timezone, not the offset
A future event saved as "UTC+1" will be wrong the moment the rules change, and they change more often than people expect — governments alter daylight saving dates with a few months' notice. Storing Europe/London and resolving the offset at display time survives that.
The transition weeks are when things break
Between the US switching in mid-March and Europe switching at the end of the month, transatlantic gaps are an hour off their usual value for about two weeks, and again for one week in autumn. Recurring calls set by their nominal time slide; calls anchored to one participant's timezone stay put for them and move for everyone else.
One hour happens twice, and one never happens
When clocks go back, local times in the repeated hour are ambiguous — 01:30 occurs twice. When they go forward, times in the skipped hour do not exist. Scheduling anything in those windows is asking for trouble, and code that parses local times has to decide which one it means.
UTC is not GMT, quite
They agree to within a second, and for scheduling they are interchangeable. UTC is the atomic standard with leap seconds; GMT is a timezone that the UK uses in winter. Using UTC as the reference in anything technical avoids the confusion, especially since the UK is not on GMT for half the year.
Limitations & Accuracy Notes
- Uses your browser's IANA timezone database. A browser that has not been updated in years may have stale rules for countries that changed them recently.
- Historical dates far in the past may be inaccurate; timezone rules before the twentieth century are patchy and in some places were local solar time.
- Future dates assume current rules stay in force, which is not guaranteed.
- The list of zones comes from the browser where it supports enumerating them, and falls back to a curated list otherwise.
- Does not model leap seconds, which matter for precision timing but not for scheduling.
Frequently Asked Questions
How does the world clock handle Daylight Saving Time (DST)?
Which major cities are tracked?
Does it handle daylight saving automatically?
Why do some zones have offsets that are not whole hours?
Why did a country's offset change recently?
What is the difference between UTC and GMT?
Why do northern and southern hemisphere clocks drift apart twice a year?
Is my data stored?
References & Further Reading
- IANA Time Zone Database — The authoritative source of timezone rules, which browsers ship a copy of
- MDN — Intl.DateTimeFormat — The browser API used to resolve offsets for a given instant