Time

Timezone Converter

Compare a date and time across multiple timezones simultaneously. Supports all IANA timezone identifiers with correct daylight saving handling.

Pick a date once and compare it across team, customer, and infrastructure timezones with daylight saving handled automatically.

Your local time

UTC

UTC

Mar 31, 2026, 03:55:00 AM

UTC+00:00

UTC

UTC

UTC

Mar 31, 2026, 03:55:00 AM

UTC+00:00

New York (ET)

America/New_York

EDT

Mar 30, 2026, 11:55:00 PM

UTC-04:00

Los Angeles (PT)

America/Los_Angeles

PDT

Mar 30, 2026, 08:55:00 PM

UTC-07:00

London (GMT/BST)

Europe/London

GMT+1

Mar 31, 2026, 04:55:00 AM

UTC+01:00

Berlin (CET/CEST)

Europe/Berlin

GMT+2

Mar 31, 2026, 05:55:00 AM

UTC+02:00

India (IST)

Asia/Kolkata

GMT+5:30

Mar 31, 2026, 09:25:00 AM

UTC+05:30

Tokyo (JST)

Asia/Tokyo

GMT+9

Mar 31, 2026, 12:55:00 PM

UTC+09:00

Shanghai (CST)

Asia/Shanghai

GMT+8

Mar 31, 2026, 11:55:00 AM

UTC+08:00

Sydney (AEDT/AEST)

Australia/Sydney

GMT+11

Mar 31, 2026, 02:55:00 PM

UTC+11:00

UTC vs local time — what's the difference?

UTC is the canonical reference time — fixed, no daylight saving adjustments, no offsets. Your local time is UTC adjusted for your timezone and any applicable DST rules. When debugging across distributed systems, always confirm which timezone your logs are in. UTC in logs is strongly preferred.

Common timezone conversion mistakes

  • Using timezone abbreviations in code: EST means UTC-5 in the US, but can mean UTC+11 in Australia. Always use full IANA names.
  • Storing local time in databases: Store UTC, convert to local only at display time. Otherwise DST transitions and user timezone changes corrupt your data.
  • Ignoring DST transition edge cases: During a DST “fall back”, the same local clock time occurs twice. During “spring forward”, one hour is skipped entirely.

UTC (Coordinated Universal Time) is the primary time standard by which the world regulates clocks. It has no timezone offset and no daylight saving time adjustments. All other timezones are defined as offsets from UTC (e.g., UTC+5:30 for India, UTC-5 for Eastern US in winter). Always store timestamps as UTC in databases.

A UTC offset (e.g., +05:30) is a fixed offset from UTC at a given moment. A timezone (e.g., America/New_York) is a named region that follows specific DST rules, so its offset changes throughout the year. Always use IANA timezone names in code, never raw offsets, to correctly handle daylight saving transitions.

The IANA Time Zone Database (also called tz database or tzdata) is the standard reference for timezone rules. Timezone names follow the format Region/City — for example, America/New_York, Europe/London, Asia/Kolkata. Use these in your code instead of abbreviations like EST or IST, which can be ambiguous.

DST advances clocks by one hour during summer months in many regions to extend evening daylight. This means a timezone like America/New_York is UTC-5 in winter (EST) but UTC-4 in summer (EDT). This converter always reflects the correct offset for the selected date, including DST transitions.

Historically, timezones were set to match local solar noon. Countries like India (UTC+5:30), Iran (UTC+3:30), and parts of Australia (UTC+9:30 or UTC+8:45) have non-standard offsets for political or historical reasons. There is no technical limitation that requires whole-hour offsets.