When it’s 9 am in London, it’s 4 am in New York, 5 pm in Singapore and 8 pm in Sydney (or 7 pm, depending on the season). Time zones exist so that local clocks roughly follow the sun, but political borders, daylight saving time (DST) and half-hour offsets make the picture messier than the neat 24 slices you might expect. This guide explains the system and how to schedule across it without mistakes. Our time zone converter handles the conversions automatically.
UTC and GMT
Coordinated Universal Time (UTC) is the world’s reference time, kept by atomic clocks and occasionally adjusted with leap seconds. Every time zone is defined as an offset from UTC, such as UTC+1 or UTC−5.
Greenwich Mean Time (GMT) is the mean solar time at the Royal Observatory in Greenwich, London. Today it is used as the name of the UK’s winter time zone and is equivalent to UTC+0 for everyday use. Computers, aviation and science use UTC, which is why flight plans and server logs show times with a “Z” (Zulu) suffix.
How offsets work
- A zone east of Greenwich is ahead of UTC (positive offset); west is behind (negative).
- Offsets are usually whole hours, but not always: India is UTC+5:30, Nepal UTC+5:45, Newfoundland UTC−3:30 and parts of Australia UTC+9:30.
- The total span runs from UTC−12 to UTC+14 (Kiribati’s Line Islands), so at some moments three different calendar dates are in use around the world.
Converting is simple arithmetic: local time = UTC + offset.
Example: a webinar starts at 15:00 UTC. In New York (UTC−4 in summer) that is 11:00; in Berlin (UTC+2 in summer) 17:00; in Mumbai (UTC+5:30) 20:30.
Time zone names vs offsets
Names like “EST” or “BST” are ambiguous (BST can mean British Summer Time or Bangladesh Standard Time) and change with the seasons. Software uses the IANA time zone database with identifiers such as Europe/London, America/New_York or Asia/Kolkata, which store the full history of offset and DST rules for each region. When storing or sharing times, use UTC or an IANA zone, not an abbreviation.
Daylight saving time rules in 2026
| Region | Clocks forward | Clocks back | Rule |
|---|---|---|---|
| UK and EU | Sun 29 March 2026, 01:00 UTC | Sun 25 October 2026, 01:00 UTC | Last Sunday of March and October, same instant everywhere |
| US and Canada (most areas) | Sun 8 March 2026, 02:00 local | Sun 1 November 2026, 02:00 local | Second Sunday of March, first Sunday of November |
| Australia (NSW, Victoria, ACT, Tasmania, SA) | First Sunday of October | First Sunday of April | Southern hemisphere: summer time runs October to April |
| New Zealand | Last Sunday of September | First Sunday of April |
No DST: most of Asia (including China, Japan, India), most of Africa, Arizona (except the Navajo Nation), Hawaii, Queensland and Western Australia. Türkiye stays on UTC+3 all year, as does Russia (Moscow time). Several countries have abolished DST in recent years, and the EU voted in principle to end clock changes in 2019, but the change has not been implemented. In the US, bills to make DST permanent have been introduced repeatedly; as of October 2026 none has become law, so the clocks still change.
What this means in practice
- UK: GMT (UTC+0) in winter, BST (UTC+1) in summer.
- Central Europe: CET (UTC+1) in winter, CEST (UTC+2) in summer.
- US East Coast: EST (UTC−5) in winter, EDT (UTC−4) in summer.
- US West Coast: PST (UTC−8) / PDT (UTC−7).
The “mismatch weeks”
Because the US changes earlier in spring and later in autumn, the gap between Europe and North America shrinks by an hour for a few weeks:
| Period (2026) | London–New York | Berlin–New York |
|---|---|---|
| Normal | 5 hours | 6 hours |
| 8–28 March | 4 hours | 5 hours |
| 25 October – 31 October | 4 hours | 5 hours |
Recurring meetings set in one city’s time will appear an hour early or late in the other for those weeks. The gap between London and Sydney swings between 9, 10 and 11 hours through the year because the hemispheres change in opposite directions.
Scheduling meetings across time zones
- Find the overlap. Working hours of 09:00–17:00 in London and New York overlap only from 14:00 to 17:00 London time (09:00–12:00 New York).
- Rotate the pain. For teams spanning the US, Europe and Asia there is no comfortable slot; alternate early and late meetings fairly.
- Send invites from a calendar app. Calendar invites store times in UTC and display them in each attendee’s local zone, adjusting for DST automatically.
- Write the zone explicitly in emails: “Tuesday 14:00 UK time (09:00 New York, 22:00 Singapore)”.
- Watch the date line. A Monday 9 am call in Sydney is Sunday afternoon or evening in Europe and the US.
- Double-check the change weeks above for recurring meetings.
Time zones for developers
- Store timestamps in UTC (or as Unix time) and convert to local time only for display; see our Unix timestamp guide.
- Never hard-code offsets like “+01:00” for a city; use the IANA zone so DST is handled.
- Beware of local times that don’t exist (02:30 on the spring-forward night in the US) or happen twice (01:30 on the fall-back night).
- Use ISO 8601 format with an offset, such as
2026-10-08T14:00:00+01:00.
Common mistakes
- Using “EST” in summer when you mean EDT.
- Assuming every country changes clocks on the same day.
- Forgetting half-hour and 45-minute offsets.
- Booking travel without checking that an overnight flight crosses the date line.
Checklist
- Convert via UTC: find each location’s current offset, including DST.
- Check DST dates for every region involved, especially in March, October and November.
- Use calendar invites or IANA zone names rather than abbreviations.
- State times with the zone in writing.
Travelling across many zones? Our jet lag guide explains how to adjust your body clock.