Guide

How to Convert Time Zones Correctly

A time zone is a set of rules that turn an absolute instant into a local civil date and time. The rules belong to a region, not to a three-letter abbreviation. When you convert 10:00 in New York to London, you are not adding a memorized number of hours to a clock face. You are asking what London’s calendar shows at the same instant.

Meridian Hours is a browser-based time zone converter. It uses IANA identifiers such as America/New_York and Europe/London, and it reads offsets from the time zone data installed in the browser. Those data can lag legal changes. The tools do not set official policy.

UTC, local time, and named zones

Coordinated Universal Time (UTC) is the reference scale. A UTC offset says how far local civil time sits from UTC at a particular instant. Local time is what a clock on the wall is supposed to show after applying that offset. Named time zones group a place with its history of offsets, including seasonal changes and one-off political shifts.

GMT is related but not a drop-in synonym in every technical or historical discussion. For conversion work, name the zone (Europe/London) or state UTC plus the numeric offset at that instant.

Converting between cities

Pick a source local date and time, a source zone, and a destination zone. Resolve the source civil time to an instant, then format that instant in the destination zone. The destination date may differ. Identical-zone conversion should return the same civil time. Non-whole-hour zones such as Asia/Kolkata must keep the 30-minute component.

Worked example: New York to London in January

Use 15 January 2026, 10:00 in America/New_York. In typical current rules that winter morning is UTC−05:00, so the instant is 15:00 UTC. Europe/London in January is typically UTC+00:00, so the converted local time is 15:00 on the same date. Confirm it with the converter rather than memorizing “five hours later” for every month.

Worked example: New York evening to Sydney

Use 20 January 2026, 18:00 in America/New_York. January is summer in Sydney. The same instant is often already the next calendar morning in Australia/Sydney. If you print only “7:00 AM” without a date, a reader can book the wrong day. The converter’s day-difference line exists for that reason.

Daylight saving time

Some zones change offsets seasonally; many never do. Transition instants are usually not midnight, and countries do not share a single changeover date. Around those instants a local time can be missing (spring forward) or repeated (fall back). A correct converter explains the gap or fold instead of quietly rewriting the field. See the DST checker and the article on daylight saving time.

Why fixed offsets mislead

Writing “New York is UTC−5” is a winter slogan, not a conversion function. In periods when the US has already changed clocks and the UK has not, the New York–London gap is not the January gap. Los Angeles and New York usually differ by three hours, but only while both follow the same seasonal regime. Phoenix does not follow the same pattern as Denver. A converter that always adds five or always adds nine will be wrong on ordinary weekdays.

Common conversion mistakes

• Using EST, CST, or IST without a city.
• Ignoring the destination date.
• Treating AM/PM casually in email.
• Assuming every country changes clocks.
• Subtracting clock faces across a DST skip and calling it elapsed time.

The time difference calculator shows both offsets at the chosen instant so you can see the subtraction. The meeting planner applies duration to the instant, not to the local hour arithmetic.

Using an online converter

On this site, set America/New_York and Europe/London as the defaults, enter the real date, and press Convert time. Swap keeps the instant. Use current time reads this device clock. Copy result includes both zones and their offsets. Save preferences stores only those two zone ids in localStorage if you ask it to.

Think of the source fields as a civil time, not as “the true time.” If you edit 10:00 after a swap, you are declaring a new wall-clock time in the new source zone, which is a new instant. If you swap without editing, the desk keeps the previous instant and only the labels change. Mixing those two intentions is how people accidentally move a meeting by five hours while believing they only “flipped the cities.”

Non-whole-hour destinations deserve a second look at the minutes. A conversion into Asia/Kathmandu or Australia/Adelaide that lands on :00 when the source was :00 may still be correct, but only because both the source offset and the destination offset happened to share the same minute component at that instant. Do not “clean up” a :45 result to the next hour for a nicer slide.

When you publish a converted time, publish the zone identifier or the numeric offset with the date. “3 PM London time on 15 January 2026” is usable. “3 PM GMT” on a date you have not checked is how winter vocabulary leaks into summer mail. The converter’s copy line is designed so you can paste both sides without retyping.

FAQ

Can I convert with a spreadsheet of offsets?

Only if you still look up the offset for that date and zone. A single stored number is not a zone.

Why did the destination date change?

Because the instant sits on a different local calendar date. That is expected, not an error.

Does this site know next year’s legal changes?

It knows whatever rules are in the browser database. Future law can differ.

Continue with time differences or open the converter.