Timezone converter

Type a date, a time, and zones. Warsaw 2024-01-01 12:00 gives 2024-01-01 11:00 UTC. 2024-07-01 12:00 gives 2024-07-01 10:00. UTC 00:00 stays 00:00. Frozen ISO from the JSON.

The same instant through IANA (Intl). Extras freeze dates from the JSON. Unix stamps sit on Unix Timestamp Converter.

Input data

Pick a place from the list β€” each maps to an IANA zone (e.g. New York = America/New_York). Daylight saving is applied automatically.

Additional zones (optional)
Quick pairs:

Results

Enter data and click Calculate.

How to use this calculator

  • Pick a date and time, plus source and target zones. Optionally add up to 4 extra zones.
  • Offset and daylight saving (DST) are computed for the date you chose β€” the result is the same instant: source local, target local, and UTC.
  • City-pair presets only fill fields; click Calculate for results.

How it works

Timezone converter in this calculator counts UTC from the typed date. Warsaw 2024-01-01 12:00 gives 2024-01-01 11:00. 2024-07-01 12:00 gives 2024-07-01 10:00. UTC 2024-01-01 00:00 gives 2024-01-01 00:00. Extras take frozen ISO from the JSON, not the browser clock.

Fields: tz-date, tz-time, tz-from, tz-to. In winter Warsaw is UTC+1, so 12:00 becomes 11:00. In summer UTC+2, so 12:00 becomes 10:00. Midnight UTC stays 00:00. The result is the UTC stamp.

11:00 is not a live World Clock. 10:00 does not come from a zone API. 00:00 does not know your today. You type the date. The calculator does not ask a time server.

Unix Timestamp Converter next door reads 1704067200 as ISO. Cron times a schedule. Here 2024-01-01 12:00 from Warsaw stays 2024-01-01 11:00 UTC.

Type 2024-01-01, 12:00, Europe/Warsaw and America/New_York, then Calculate. Extras UTC is 2024-01-01 11:00. This is not a live clock.

2024-01-01 12:00 Warsaw gives 11:00 UTC. 2024-07-01 12:00 gives 10:00. UTC 00:00 stays 00:00. Another date changes 11:00.

Formula

the same instant through an IANA zone (Intl). The result is UTC. Frozen ISO from the JSON, not a clock.

How to use

  1. Type 2024-01-01, 12:00, Europe/Warsaw.
  2. Click Calculate. Extras UTC is 2024-01-01 11:00.
  3. 2024-07-01 12:00 gives 2024-07-01 10:00. UTC 00:00 stays 00:00.
  4. Frozen ISO from the JSON, not a clock.
  5. Unix stamps sit on Unix Timestamp Converter.

Warsaw 2024-01-01 12:00 = 11:00 UTC

Frozen ISO from the JSON. 2024-01-01 12:00 gives 2024-01-01 11:00.

Timezone
tz-from and tz-to. Warsaw in winter gives 11:00. In summer 10:00.
converter
Date, time, and IANA. 2024-01-01 12:00 leaves 11:00 UTC.
UTC
The result. 2024-01-01 00:00 UTC stays 00:00. Not a clock.

Examples

Example 1

  • 2024-01-01 12:00
  • Europe/Warsaw
  • America/New_York

2024-01-01 11:00

What UTC at Warsaw 2024-01-01 12:00? 2024-01-01 11:00. Frozen ISO from the JSON.

Example 2

  • 2024-07-01 12:00
  • Europe/Warsaw
  • UTC

2024-07-01 10:00

What UTC at 2024-07-01 12:00? 2024-07-01 10:00.

Example 3

  • 2024-01-01 00:00
  • UTC
  • America/New_York

2024-01-01 00:00

What UTC at UTC 00:00? 2024-01-01 00:00.

Related calculators

Common questions

What UTC at Warsaw 2024-01-01 12:00?

2024-01-01 11:00. Winter UTC+1. Frozen ISO from the JSON.

What UTC at 2024-07-01 12:00?

2024-07-01 10:00. Summer UTC+2.

What UTC at UTC 00:00?

2024-01-01 00:00. Midnight stays midnight.

Is this a live clock or World Clock?

No. A typed date. Extras keep ISO from the JSON.

Does the calculator know DST?

Yes, through Intl and IANA. January and July give 11:00 and 10:00.

Does New York change primary UTC?

No. The result is the UTC stamp. The target sits beside it.

Is 11:00 today?

No. Extras freeze 2024-01-01. There is no Date.now.

Where do I convert Unix 1704067200?

On Unix Timestamp Converter. Here 2024-01-01 11:00 stays.

Does a blank date count?

No. Date and time must be typed. This is not a live clock.

Knowledge sources

The calculator counts bits, bytes or throughput from your numbers. Below are SI and bit definitions (NIST).

Page updated in 2026.

Offsets and UTC

Every IANA zone (e.g. America/New_York) has an offset from UTC (-05:00 or -04:00 in summer) β€” a clock shift, not a separate "speed" of time. UTC is the reference point with no shift and no daylight saving, so the calculator always shows the same instant in UTC too.

Daylight saving time (DST)

  • Many zones change their offset twice a year (e.g. US: second Sunday of March and first Sunday of November) β€” this changes the hour difference versus zones without DST (e.g. UTC, most of Asia).
  • Some city pairs have an hour difference that itself changes during the year, because only one side observes DST (Europe and the US switch on different dates).
  • This calculator computes the offset for the specific date you pick β€” not "right now" β€” so the result is correct for future dates too.

Worked example: a meeting across a DST change

The same local clock time in Warsaw the week before and after Europe’s spring-forward maps to a different New York time, because the US and Europe change clocks on different dates.

Date (Warsaw)SourceTarget (New York)Note
2026-03-22 15:00Europe/Warsaw (UTC+1)~10:00 America/New_York (UTCβˆ’4)Europe still winter; US already on DST
2026-03-29 15:00Europe/Warsaw (UTC+2)~09:00 America/New_York (UTCβˆ’4)After Europe’s spring-forward β€” 1 hour shift vs the prior week

Try both dates in the calculator β€” your browser’s Intl engine supplies the offsets.

Offsets: winter vs summer (ballpark)

PairWinterSummer
Warsaw β†’ New York~6 h~6 h (change dates differ!)
London β†’ Tokyo~9 h~8 h
UTC β†’ Los Angeles~8 h~7 h

Around DST transition weeks the gap can temporarily differ β€” always compute for a concrete date.

Meeting-scheduling pitfalls

  • "3pm my time" doesn’t mean the same hour for the other person β€” always state the zone or share a converter link.
  • The week of a DST transition is confusing because the hour difference between zones temporarily shifts.
  • Calendar apps handle recurring UTC-based meetings well, but can "drift" a meeting by an hour if it was saved in local time without a zone.

Why you should store UTC

In databases and logs, store time in UTC and convert to local time only in the presentation layer (UI). This removes DST ambiguity and lets you correctly compare and sort events from different zones without extra logic.

Examples

  • 12:00 in Warsaw (summer, UTC+2) = 06:00 in New York (UTC-4) = 10:00 UTC.
  • 09:00 in London (winter, UTC+0) = 18:00 in Tokyo (UTC+9) the same day.
  • A meeting saved as "weekly at 10:00 local time" can land on a different UTC hour after a DST change in either zone.