Timezone Converter
A timezone converter shows one moment as it appears across multiple timezones at once. Enter a date and time, pick the zone you are working from, and epochkit renders the equivalent local time in up to six zones side by side — using the IANA Time Zone Database, with daylight saving time applied automatically.
-
—
-
—
-
—
How to use
- 1
Set a reference time
Enter any date and time in the input above and choose the timezone you're working from. All rows update instantly.
- 2
Add or remove timezones
Click "Add timezone" to add a row (up to 6). Use the dropdown on each row to pick any IANA timezone. Click × to remove a row.
- 3
Your list is saved
Your timezone selection persists via localStorage. Reopen the page and your preferred zones are already loaded.
About timezone conversion
The IANA Time Zone Database (also called
the tz database or Olson database) is the authoritative, community-maintained record of every
timezone in the world, and it is the source of every zone offered in this tool. It powers
timezone support in Linux, macOS, Java, Python, Go, PostgreSQL, and most modern programming
environments. The database is updated several times a year as governments revise their rules.
IANA identifiers follow the Region/City format — America/New_York, Europe/London, Asia/Kolkata — and each identifier encodes the zone's complete offset history, including every daylight saving
rule change ever legislated. Abbreviations cannot do this: EST could mean Eastern Standard Time
(UTC−5) or Australian Eastern Standard Time (UTC+10), and IST is used for India, Israel, and Ireland
alike. That ambiguity is why APIs, databases, and configuration files should store IANA identifiers
rather than abbreviations, and why this converter is built exclusively on them.
Daylight Saving Time (DST) is the practice
of shifting clocks forward, usually by one hour, for part of the year — and it is the most common
source of timezone bugs in production systems. This converter handles DST automatically: the IANA
database encodes every historical and future transition, so picking a summer date in America/New_York applies UTC−4 (EDT) while a winter date applies UTC−5 (EST), with no manual adjustment. The
edge cases matter most. During the spring-forward transition an entire local hour does not exist;
during fall-back one local hour occurs twice. Fixed-offset arithmetic — "EST is UTC minus five"
— silently produces wrong results across those boundaries. Regions also switch on different dates:
the United States changes in March and November, the European Union in March and October, and
Japan and India never switch at all. Checking a specific date here confirms the exact offset in
force at that moment.
Developers often confuse UTC, GMT, and Z.
For practical purposes they all mean UTC+0, but UTC is the precise scientific standard; GMT is
the historical mean solar time at the Greenwich meridian; and Z (Zulu) is the ISO 8601 and military
shorthand for UTC+0. When writing timestamps in API responses, append Z (e.g., 2026-05-09T18:00:00Z) or
include an explicit offset like -07:00.
A safe rule of thumb for distributed systems: store in UTC, display in the user's local timezone. UTC timestamps are unambiguous, sortable, and unaffected by DST transitions. Convert to local time only at the display layer. This converter lets you verify that your conversion logic produces the expected output across any combination of zones before you ship.
Popular conversions
Working with one specific pair of zones? Each page below converts directly between two timezones — useful when you bookmark or share a single conversion.
UTC conversions
US time zones
Frequently asked questions
Why does epochkit use "America/New_York" instead of "EST" or "ET"?
Abbreviations like EST, IST, or CST are ambiguous — EST could mean Eastern Standard Time (UTC−5) or Australian Eastern Standard Time (UTC+10). IANA timezone identifiers like "America/New_York" are unambiguous, encode DST rules automatically, and are the standard used by all major programming languages and operating systems.
Does the converter handle Daylight Saving Time automatically?
The converter applies Daylight Saving Time automatically for every zone. IANA timezone rules include all historical and current DST transitions, so when you pick "America/New_York", the converter applies UTC−5 in winter (EST) and UTC−4 in summer (EDT) based on the exact date and time you enter. No manual adjustment is needed, even across the spring-forward and fall-back boundaries.
What is the difference between UTC, GMT, and Z?
UTC (Coordinated Universal Time) is the modern international time standard. GMT (Greenwich Mean Time) refers to the mean solar time at the Greenwich meridian — for everyday purposes they are equivalent, but UTC is the precise scientific standard. Z (Zulu) is the military and ISO 8601 shorthand for UTC+0. All three represent the same offset; prefer UTC or Z in API responses.
Are there timezones with a fixed offset that never change for DST?
Several timezones keep a fixed offset year-round and never observe DST. UTC itself, Asia/Tokyo (JST, always UTC+9), and Asia/Kolkata (IST, always UTC+5:30) are common examples. If you need a guaranteed fixed offset, use "Etc/GMT+5" style identifiers — though note these use the POSIX sign convention, so "Etc/GMT+5" is actually UTC−5.
How do I specify a timezone in API requests?
Most REST APIs accept IANA timezone identifiers as strings — for example, the Google Calendar API uses "timeZone": "America/Los_Angeles". If an API requires a UTC offset instead, use ISO 8601 format: 2026-05-09T18:00:00-07:00. Avoid passing abbreviations (EST, PST) as they are not standardized across APIs.