Time Zone Abbreviations

Time zone abbreviations like PST, EST, CET are the human-readable shorthand for time zones. The reference page above is a lookup table. This companion explains why abbreviations are unreliable for programmatic use and what to use instead.

The familiar abbreviations

In US locations that observe DST, standard time applies outside the daylight-saving period. Some locations keep standard time all year. Other regions use different conventions.

The ambiguous abbreviations

A surprising number of three-letter abbreviations refer to multiple distinct zones:

A datetime tagged “CST” without context can differ by 14 hours between the US and Chinese meanings. For computing, never use abbreviations as the canonical identifier of a zone.

IANA / Olson timezone identifiers

The unambiguous form is the IANA database identifier:

America/New_York
America/Los_Angeles
America/Chicago
Europe/London
Europe/Paris
Asia/Tokyo
Asia/Kolkata          (was Asia/Calcutta)
Asia/Shanghai
Australia/Sydney

Geographic identifiers usually use Area/Location; non-geographic identifiers such as Etc/UTC also exist. The city is the canonical city representing the zone (the largest, the capital, or historical reasons). Multiple cities in the same zone have aliases — Asia/Calcutta is now Asia/Kolkata, with the old name kept as an alias.

The IANA database is the canonical source maintained collaboratively. It records civil-time rules and is updated as governments change them; historical coverage, especially before 1970, is incomplete. Most operating systems, programming languages, and databases bundle it.

Programming with timezones

These APIs accept IANA identifiers. Other APIs may use Windows zone names or fixed offsets:

# Python
from datetime import datetime
from zoneinfo import ZoneInfo

dt = datetime.now(ZoneInfo("America/New_York"))

// JavaScript (Intl)
new Intl.DateTimeFormat('en-US', { timeZone: 'America/New_York' }).format(new Date());

These all use the IANA identifier. The string "EST" may or may not be accepted; behavior varies. An API may treat EST as a fixed −05:00 offset. That is not New York civil time in July, when the city normally observes EDT at −04:00.

DST handling

With the relevant time-zone data installed, an IANA-aware library can apply rules such as:

• America/New_York is EST (-05:00) in winter and EDT (-04:00) in summer.
• The transition dates change over time (Congress moved them; the library knows when).
• Some places (Hawaii, Arizona except the Navajo Nation, much of Asia) don’t observe DST.

If the requirement is “9 AM in New York every day,” store that wall time and America/New_York. A fixed EST offset expresses a different requirement. Keep the underlying time-zone data updated.

UTC offsets are unambiguous

For an already-resolved instant, include an explicit offset:

2026-04-30T14:00:00Z              ← UTC
2026-04-30T10:00:00-04:00         ← same instant, EDT
2026-04-30T19:00:00+05:00         ← same instant, +05:00 (no city specified)

These three timestamps identify the same instant. An offset alone does not identify a regional zone or its future rules. A recurring appointment also needs the local schedule, zone, and a policy for skipped or repeated times at DST transitions.

When abbreviations are still useful

• Human display. Showing “9:00 AM EST” to a user in the US is more readable than “9:00 AM America/New_York.”
• Email signatures and meeting invites. Common practice; the recipient usually understands their own region’s abbreviation.
• Newspaper datelines. Tradition.
• Scheduling. Include the date and location, or use a calendar invite that carries the zone. Los Angeles uses PDT during its daylight-saving period, not PST.

For storage, comparison, computation: use IANA. For display: use the abbreviation if it makes sense to the user.

Common pitfalls

• new Date("2026-04-30 14:00 EST") in JavaScript. This is not the standardized JavaScript date-time string format; parsing is implementation-dependent. Don’t pass abbreviations to date parsers.
• Storing "PST" in a database. A fixed PST offset stays −08:00. It will not follow Pacific daylight time. Store an instant for a completed event, and the regional zone plus wall-time rule for a recurring schedule.
• Assuming abbreviations are unique. They aren’t.
• Hardcoding offsets that change. A zone’s offset can change (Russia restructured its zones in 2014; Samoa skipped a day in 2011). IANA-aware libraries track this; offset-based code doesn’t.
• Ignoring zone history. “What time was it in New York at 1985-04-30T14:00:00Z?” requires knowing the DST rules in 1985, which differed from today. IANA includes historical rules.

For the unambiguous form to use programmatically, see the IANA Time Zone Database. For the related Unix timestamp tool, see timestamp converter.

Sources and scope

Checked September 27, 2026: IANA time-zone theory, Python zoneinfo, JavaScript date parsing, and Intl.DateTimeFormat. Offset examples were checked as equal instants.