"Just subtract 5 hours for Eastern Time." This advice works most of the time and fails catastrophically the rest. The "rest" includes Daylight Saving Time transitions, half-hour and quarter-hour offset zones, zones that change their UTC offset permanently, and the International Date Line.
Time zones are a political construct, not a mathematical one. They change based on legislation, not physics. And that makes them the worst kind of engineering problem: one where the rules are ambiguous and mutable.
The IANA time zone database
The only reliable way to handle time zones is the IANA (Internet Assigned Numbers Authority) time zone database, also called the Olson database. It contains the complete history of time zone rules for every region, including all DST transitions, offset changes, and political redefinitions.
A time zone is not a fixed offset. "Eastern Time" is not "UTC-5." It is "America/New_York," which is UTC-5 during standard time and UTC-4 during Daylight Saving Time. The transition dates have changed multiple times -- the US moved them in 2007 (Energy Policy Act of 2005).
Using IANA identifiers instead of fixed offsets is critical because the identifier carries the full rule set. new Date().toLocaleString('en-US', { timeZone: 'America/New_York' }) always gives the correct local time in New York, regardless of whether DST is in effect.
The weird zones
UTC+5:30. India Standard Time. The entire country of 1.4 billion people uses a single time zone with a 30-minute offset.
UTC+5:45. Nepal. 15-minute offset from India, the only country using this offset.
UTC+8:45. Eucla, Western Australia. An unofficial time zone used by a small community.
UTC+13 and UTC+14. Parts of the Pacific. Kiribati's Line Islands are UTC+14, which means they are the first place on Earth to enter each new day -- and they are west of Hawaii (UTC-10), which is nearly last.
UTC-9:30. Marquesas Islands (French Polynesia). Another half-hour offset.
These zones mean that "converting time zones by subtracting hours" does not even work for integer offsets, let alone the half-hour and quarter-hour ones.
DST transitions create ambiguity
During the fall-back transition, the local time 1:30 AM occurs twice -- once in daylight time and once in standard time. If someone says "I'll call you at 1:30 AM Eastern on November 3," which 1:30 AM? Without specifying the offset (EDT or EST), the time is ambiguous.
During the spring-forward transition, 2:30 AM does not exist. The clock jumps from 2:00 AM to 3:00 AM. Scheduling a meeting at 2:30 AM on March 9 in a US time zone is an error.
// This time doesn't exist in America/New_York in spring 2026
new Date('2026-03-08T02:30:00-05:00')
// JavaScript will "fix" it by shifting, potentially to a wrong time
The conversion you actually need
What time is 3:00 PM in Tokyo when it is that time? That depends on the date (because DST rules differ).
In winter: Tokyo is UTC+9. New York is UTC-5. Difference: 14 hours. 3 PM Tokyo = 1 AM New York.
In summer: Tokyo is UTC+9. New York is UTC-4. Difference: 13 hours. 3 PM Tokyo = 2 AM New York.
Japan does not observe DST, but New York does. So the conversion changes even though only one side shifts.
The tool
I built a timezone converter at zovo.one/free-tools/timezone-converter that uses the IANA database for accurate conversions across all zones, including half-hour offsets and DST transitions. Select source and target time zones, enter a date and time, and get the correct conversion. It flags DST transitions and ambiguous/nonexistent times. No more mental arithmetic with offsets that might be wrong.
I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.
Top comments (0)