How Time Zone Conversion Works (and Why DST Trips People Up)

Every time zone is defined as an offset from UTC, the global reference time. New York in winter is UTC minus five hours; Tokyo is UTC plus nine. To convert a moment from one place to another, you shift by the difference between their offsets. If it is 3:00 PM in a UTC minus five zone, it is 8:00 PM UTC and 5:00 AM the next day in Tokyo.

The catch is that many regions do not keep a single offset all year. They shift forward in spring and back in autumn for daylight saving time, so New York is UTC minus five in January but UTC minus four in July. A conversion that uses a fixed offset will be wrong for half the year.

Daylight saving time is not global, and the regions that observe it do not switch on the same dates. The United States and Europe change on different weekends, so for a couple of weeks each spring and autumn the gap between New York and London is one hour off from its usual value. Much of Asia, Africa, and the tropics do not observe DST at all, and in the southern hemisphere the shifts run in the opposite direction.

This is why converting between two cities requires knowing the exact date, not just the clock time. The offset between London and Sydney is different in June than in December because one is in summer while the other is in winter. Any tool that ignores the date will silently produce a time that is an hour or two off.

The reliable way to handle all of this is to use IANA time zone names such as America/New_York, Europe/London, or Asia/Kolkata rather than raw offsets like GMT minus five. Each IANA zone carries the full history and future rules of when that region changes its clocks, so software can compute the correct offset for any specific date automatically.

Using named zones also handles the messy edge cases: regions that changed their DST rules, places with half-hour or 45-minute offsets like India and Nepal, and areas that abolished DST recently. Picking a city rather than an offset means the conversion stays correct even as the rules evolve.

The converter applies the correct offset for the date you enter, so daylight saving is handled for you rather than left as mental arithmetic. That makes it practical for scheduling calls, catching a broadcast, or coordinating a launch across teams in different countries.

The trickiest cases sit right on the changeover weekends. If you schedule a recurring call for a fixed local time, the absolute UTC moment shifts by an hour when one region springs forward before the other, so a call that felt like 9:00 AM for both sides can drift out of sync until the second region also changes. Confirming with a date-aware conversion around March and November avoids the surprise.

Storing and sharing times in UTC, then converting to local zones only for display, sidesteps most of these problems. It gives everyone a single unambiguous reference and lets each person's tools apply their own zone rules to show the right local clock time.