🔧 TL3 Tools

One instant, two clocks

When a meeting spans continents, the same moment exists under different names. This converter takes one date and time and shows it in two time zones at once: pick the source zone from the From dropdown, pick the target zone from the To dropdown, and press Convert. The result shows the target time in a large readout, with the source time and both zones listed underneath, each annotated with its UTC offset. The readout runs on a twelve-hour clock with seconds and full month names, so a result like July 15, 6:00:00 PM leaves no room for a.m./p.m. guesswork.

The dropdowns open with America/New_York as the source and Europe/London as the target, so a first conversion works with zero configuration. The swap button (⇄) flips the two selections and immediately converts again — handy for checking the return trip.

Worked example: Los Angeles to Paris, twice

The clearest way to see daylight saving at work is the same pair of cities in two seasons. With your device clock set to Pacific time, choose America/Los_Angeles as From and Europe/Paris as To.

In July, enter a date in summer — say July 15 at 09:00. Los Angeles is on Pacific Daylight Time, UTC−7, so 09:00 there is 16:00 UTC, and Paris on Central European Summer Time, UTC+2, reads 18:00. The converter returns July 15, 6:00 PM for Europe/Paris (UTC+02:00).

In January, enter January 15 at 09:00. Now Los Angeles is on Pacific Standard Time, UTC−8, pushing the same 09:00 to 17:00 UTC, and Paris on Central European Time, UTC+1, again shows 18:00. Same wall-clock pair, different offsets — the hour difference between the two cities stays nine, but the relationship to UTC shifts with the season.

Bigger jumps come with a date change. Point the converter at America/New_York and Asia/Tokyo in July: New York sits at UTC−4, Tokyo at a constant UTC+9 — it never observes daylight saving. Enter 5:00 PM and the engine lands on 6:00 AM the next morning; the converted date matters as much as the hour, which is why the readout always carries the full date.

What the conversion is actually doing

The dropdowns are populated from the browser's own list of supported time zones, exposed through Intl.supportedValuesOf('timeZone') — the same IANA identifiers your operating system and most programming languages use, such as America/Los_Angeles and Europe/Paris. If that API is unavailable, a fallback list of twenty-three common zones loads instead.

Conversion itself is one trick: the page creates a single instant from your input and formats that same instant twice, once per zone, using the built-in Intl.DateTimeFormat. Because the instant is fixed, no arithmetic is ever done by hand — the engine applies each zone's rules, including its daylight saving schedule, for the exact date you chose. The UTC offset next to each zone is computed for that same date, which is why it can say UTC+02:00 in July and UTC+01:00 in January for the very same city.

Where timezone conversion gets slippery

• Your input is read as your device's time. The datetime field carries no timezone marker, so the browser treats what you type as its own local wall-clock time. If your computer is set to Berlin but you intend Los Angeles as the source, type 09:00 and you will convert Berlin's 9 AM — double-check the Source Time row.
• Abbreviations are ambiguous. "CST" could mean China, Central US, or Cuba. That is why the dropdowns use IANA names instead; the abbreviation you are used to maps to different zones in different contexts.
• Spring-forward hours do not exist. On the day clocks jump ahead, local times like 02:30 simply never occur. The engine still resolves an instant — typically the one an hour later — so the converted output may not show the wall-clock hour you typed.
• Fall-back hours occur twice. When clocks turn back, one wall-clock hour happens twice. The engine picks a single interpretation, and the offsets displayed are for that one.
• Garbage in, garbage out. If your device clock or timezone setting is wrong, every conversion is wrong by the same amount. The tool trusts the operating system's clock and zone data.
• Zone rules age with your OS. The conversion applies the IANA data bundled with your operating system. When a country changes its clocks — a repeated political event — the new rules arrive via system updates; an outdated OS can keep showing a stale offset.

Timezone questions that come up

Why does the offset next to a city change across the year?

Because most zones observe daylight saving time. The offset is computed for the exact date you entered, so Paris shows UTC+02:00 in summer and UTC+01:00 in winter — same city, different season, different offset. That is the mechanism behind the "extra" hour.

Why doesn't the dropdown offer "PST" or "CEST"?

Those are abbreviations, and each one maps to several different zones depending on who says it. The dropdowns carry IANA identifiers — America/Los_Angeles, Europe/Paris, Asia/Tokyo — which are unambiguous and understood by every operating system and language runtime.

Is the time I type interpreted in the From zone or my own?

Your own. The datetime field stores no zone, so the browser reads the typed value as its local time before projecting it to the From zone. If your device clock matches the From zone — the usual case — the result is exactly what you expect; otherwise check the Source Time row to confirm.

What happens if I enter a time in the spring-forward gap?

That wall-clock time never existed locally, so the engine resolves the closest real instant — typically one hour later — and converts that. The output stays internally consistent, but the converted hour will not match the one you typed.

Does the swap button really convert again?

Yes. Swapping exchanges the two dropdown selections and immediately re-runs the conversion, so the result reflects the reversed direction without a second click.

Where this converter fits

It earns its place when a specific moment matters: locking a meeting time so every attendee sees their own local equivalent, converting a deadline announced in another zone, or sanity-checking a timestamp in code during a debugging session. The precise date input and per-date offsets make it better than a static "current time" widget for anything anchored to a particular hour.

It is less useful when you only need "what time is it there now" — a world clock covers that in one glance — or when the exact instant is a legal or contractual stake, where you should confirm against an authoritative source. For everyday scheduling across borders, it is the fastest way to a number you can trust.