Time zone reference
A UTC offset reference for major cities worldwide: offsets are computed for the date you pick via Intl, daylight saving is reflected automatically, and you can sort by offset or group by region.
Runs in your browserEvery computation happens in your browser — your data never leaves this device.
Query
Offsets are computed for this exact day, so daylight saving changes show up automatically.
The city and time zone id list is static and was compiled in 2026-10; every offset is computed live by the browser’s Intl.DateTimeFormat for the date you choose, so nothing like a hardcoded +8 can go stale when DST rules change.
Reference table
Pick a date to see the UTC offset of each city.
Versus UTC
What this tool does
- Check before scheduling a cross-time-zone call: set the meeting date and see whether New York is at UTC−4 or UTC−5 without digging through DST calendars.
- Sorting by offset makes it obvious which cities share a working day and which have already rolled into tomorrow — handy for cron jobs and i18n requirements.
- Debugging log timestamps: confirm what a zone’s offset actually was on that day instead of mixing standard and daylight time.
- Building a time difference cheat sheet? Copy the grouped text into your docs instead of transcribing it by hand.
Example
Input
Query date 2026-07-15, looking at New York and Shanghai
Output
New York · America/New_York · UTC-04:00 · Daylight saving; Shanghai / Beijing · Asia/Shanghai · UTC+08:00 · Standard time
Shanghai stays at +08:00 all year, while New York is on daylight saving in July at −04:00 and returns to −05:00 when you query 2026-01-15.
Frequently asked questions
Why are the offsets not hardcoded?
Daylight saving rules change often, and a hardcoded “New York = UTC−5” is simply wrong in summer. Every offset is computed live by the browser’s Intl.DateTimeFormat for the date you pick, so it follows the IANA tzdata updates without any code change.
How is daylight saving detected?
The tool compares the offset on January 15 and July 15 of the same year, treats the smaller one as standard time (which also works for the southern hemisphere), and flags the current offset as daylight saving if it is larger. It is a heuristic that holds for common zones, though edge cases such as Morocco’s Ramadan shifts may be labelled imprecisely.
Why use identifiers like Asia/Shanghai?
That is the standard IANA time zone identifier and the only form browsers’ Intl understands. Names like “Beijing time” or “GMT+8” cannot be parsed and cannot track daylight saving, so the table shows both the city name and the zone identifier.
Why is a city missing from the table?
Only major cities are included, compiled in 2026-10. If a city shares a zone with a listed one (Shenzhen and Shanghai, for example), use the listed city’s offset; when you need the exact region, rely on the IANA identifier.
Does querying make any network request?
No. The time zone data comes from the browser’s built-in Intl and time zone database, the page sends no requests, and the date you enter is never uploaded.
Keywords：time zoneutc offsetdaylight savingdstworld clock时区UTC偏移夏令时世界时间时差查询