Time Zones: UTC, Beijing Time & World Clock Conversion

Beijing

London

New York

Why it works

07:00-09:00

23:00-01:00*

18:00-20:00*

NY evening = BJ morning (winter)

20:00-22:00

12:00-14:00

07:00-09:00

Best triple overlap (winter)

21:00-23:00

14:00-16:00

09:00-11:00

BJ late night alternative

15:00-17:00

07:00-09:00

02:00-04:00*

EU only — NY asleep

Key Takeaways

UTC is the anchor: every zone is UTC±n; Beijing UTC+8, Tokyo +9, London +0/+1, New York −5/−4

Conversion: add the offset difference — Beijing 9:00 → New York (EST): 9 − 13 = −4 → 20:00 previous day

DST trap: US/EU clocks shift ±1h seasonally; China has no DST — the gap changes twice a year

Date line: crossing it changes the DATE, not just the hour — Auckland is 4-5h ahead of Beijing but "tomorrow"

Core answer: China uses a single time zone — UTC+8 (Beijing time) — across the whole country, with no daylight saving time. So when it's 12:00 in Beijing it's 20:00 the previous day in Los Angeles (UTC−8, standard) and 04:00 in London (UTC+0). The mental formula: target time = Beijing time + (target UTC offset − 8).

The offsets you actually need

City	Standard	DST period	vs Beijing (standard)
Beijing / Shanghai	UTC+8	none	0
Tokyo / Seoul	UTC+9	none	+1 h
Singapore / HK	UTC+8	none	0
Dubai	UTC+4	none	−4 h
London	UTC+0	BST = UTC+1 (Mar–Oct)	−8 h
Paris / Berlin	UTC+1	CEST = UTC+2	−7 h
New York	UTC−5	EDT = UTC−4	−13 h
Los Angeles	UTC−8	PDT = UTC−7	−16 h
Sydney	UTC+10	AEDT = UTC+11 (Oct–Apr)	+2 h

Worked examples

Example 1 — Calling New York. Beijing 21:00 − 13 h = New York 08:00 same day (standard time). During US daylight saving (Mar–Nov), the gap shrinks to 12 h: Beijing 21:00 = New York 09:00. Mornings in Beijing = evenings in the US east — the standard overlap window for trans-Pacific meetings is Beijing 20:00–23:00.

Example 2 — Flight duration sanity check. A flight departs Beijing 13:00, lands Los Angeles 10:00 "the same day": apparent duration is −3 h, but add the 16 h offset → actual flight time ≈ 13 h. Arrival + offset − departure is the formula.

Example 3 — The Date Line oddity. Flying Beijing → Los Angeles you land "earlier" than you took off; flying back you lose a calendar day. It's the International Date Line, not a scheduling error.

Example 4 — Server timestamps. Logs in UTC: a spike at 03:00 UTC = 11:00 Beijing. Always confirm whether a dashboard shows UTC, server-local, or browser-local time before diagnosing "night-time" incidents.

Daylight saving traps

The US and EU switch on different weeks — for 2–3 weeks each March and October/November the US-EU gap is off by an hour from its usual value.
China abolished DST in 1992; all "summer time" logic for Chinese users is legacy.
Southern hemisphere DST (Australia) runs October–April — opposite to the north.

Common mistakes and myths

"China has 5 time zones" — geographically it spans five, but legally everything runs UTC+8; sunrise in Kashgar can be after 10:00 in winter.
Forgetting the date flip — Beijing 09:00 Monday = Los Angeles 17:00 SUNDAY; scheduling "Monday morning" across the Pacific needs explicit dates.
Assuming offsets are integer hours — India is UTC+5:30, Nepal UTC+5:45, Iran UTC+3:30; half-hour zones break naive schedulers.
Storing local time in databases — store UTC, render local; otherwise DST transitions create duplicate or missing hours (02:30 may not exist, or may exist twice).
Believing GMT = London time year-round — London is GMT only in winter; summer is BST (UTC+1).

Frequently Asked Questions

How do I convert between time zones?

Both through UTC: local time − your offset + target offset. Beijing (UTC+8) 15:00 → London winter (UTC+0): 15 − 8 = 07:00 UTC → 07:00 London. → New York winter (UTC−5): 02:00. Negative results wrap to the previous day; over-24 wraps forward. Always track the DATE alongside the hour for far-apart zones.

Why does China have one time zone?

Since 1949, all of China uses Beijing Time (UTC+8) despite spanning five geographical zones — a political unity choice. Consequence: solar noon in Ürümqi arrives around 14:00, and Xinjiang informally keeps a local "Xinjiang time" (UTC+6) alongside. For all official, business and transport purposes: one country, one clock.

How does daylight saving time break conversions?

US shifts clocks +1h mid-March to early November; EU late March to late October; China never. So Beijing–New York is 13h (winter) vs 12h (summer); Beijing–London 8h vs 7h. The two switch WEEKS differ between US and EU, briefly creating a third offset. Recurring international meetings drift an hour twice yearly — the #1 cause of "I thought it was at 3" incidents.

What is the International Date Line?

The ±12h boundary (roughly along 180° longitude, zigzagging around nations) where the calendar date changes. Flying west across it: +1 day; east: −1 day. Extreme case: Samoa (UTC+13) and American Samoa (UTC−11) are 70 km apart but 24 hours apart. Auckland 12:00 Tuesday = Beijing 07:00 Tuesday (Nov-Mar) = Los Angeles 15:00 Monday.

What are good meeting windows across continents?

Beijing–Europe: 15:00-18:00 Beijing = 08:00-11:00 London winter — the golden overlap. Beijing–US East: 20:00-22:00 Beijing = 07:00-09:00 New York winter (tolerable); reverse direction, 21:00-23:00 New York = 10:00-12:00 Beijing next day. Beijing–US West needs real sacrifice (5-6h difference to workdays). Rotating the pain between teams is the sustainable policy.

What mistakes happen with time zones?

(1) Forgetting the date wrap — "Tuesday 9am Beijing" is "Monday 8pm New York"; (2) scheduling during DST transition weeks (a meeting at a nonexistent 02:30 local); (3) assuming all of Australia/India etc. share one zone (Australia has 3-5, India is UTC+5:30 — yes, half-hour zones exist: Nepal is +5:45); (4) "GMT" used loosely for London summer time (BST is UTC+1); (5) storing local time in databases without the zone — store UTC, render local.

Key Takeaways

The offsets you actually need

Worked examples

Daylight saving traps

Common mistakes and myths

Frequently Asked Questions

Meeting window cheat sheet