Timezone abbreviations: why EST, IST, and CST are ambiguous
Why timezone abbreviations collide, a reference table of UTC offsets for EST, CST, IST, BST and more, and why IANA identifiers like America/New_York are the reliable form.
Table of contents
TL;DR: Timezone abbreviations are not a standard and are not unique. IST means India Standard Time (UTC+05:30), Israel Standard Time (UTC+02:00), or Irish Standard Time (UTC+01:00). CST means US Central (UTC−06:00), China Standard (UTC+08:00), or Cuba Standard (UTC−05:00). BST means British Summer Time (UTC+01:00) or Bangladesh Standard Time (UTC+06:00). Use IANA identifiers — America/New_York, Asia/Kolkata — for anything a machine reads, and write a UTC offset alongside any abbreviation a human reads.
Every offset in this article was computed from the IANA time zone database at a January 15, 2026 and a July 15, 2026 reference instant, not recalled from memory.
Why abbreviations are ambiguous
A timezone abbreviation is a short label — EST, CST, IST — that names a region’s clock offset in prose. It has no governing standard, no registry, and no guarantee of uniqueness. Abbreviations grew out of local usage in dozens of countries independently, so the same letters were claimed more than once, and nothing exists to arbitrate the collisions. The IANA time zone database, which every major operating system and language runtime uses, treats abbreviations as output only: it can tell you that America/Chicago was on “CST” at a given instant, but it cannot turn “CST” back into a place. The reverse lookup does not exist because it cannot exist — the input is genuinely ambiguous. This is why an abbreviation is safe in a sentence a human reads with context, and unsafe in a database column, a log line, a config file, or an API payload.
IST: India, Israel, Ireland
Three countries, three offsets, one abbreviation. India Standard Time is UTC+05:30 all year — Asia/Kolkata returns +05:30 in both January and July. Israel Standard Time is UTC+02:00, moving to UTC+03:00 (IDT) in summer; Asia/Jerusalem computes to +02:00 in January and +03:00 in July. Irish Standard Time is UTC+01:00 and — unusually — it is the summer offset that carries the “standard” name in Ireland: Europe/Dublin computes to +00:00 in January and +01:00 in July.
The practical spread between the two extremes, India at +05:30 and Ireland at +01:00, is 4 hours 30 minutes. A meeting invite reading “14:00 IST” is not slightly wrong for the wrong reader; it is most of a working day wrong.
CST: US Central, China, Cuba
The worst offender. US Central Standard Time is UTC−06:00 (America/Chicago, January), shifting to CDT at UTC−05:00 in July. China Standard Time is UTC+08:00 year-round (Asia/Shanghai, both reference dates). Cuba Standard Time is UTC−05:00 (America/Havana, January), shifting to UTC−04:00 in July.
US Central and China are 14 hours apart at standard time. And the daylight variant collides too: “CDT” is UTC−05:00 in Chicago but UTC−04:00 in Havana — a one-hour error that looks like a rounding mistake and behaves like a missed deployment window.
BST: Britain, Bangladesh
British Summer Time is UTC+01:00 — Europe/London computes to +00:00 in January (GMT) and +01:00 in July. Bangladesh Standard Time is UTC+06:00 year-round (Asia/Dhaka, both reference dates). Five hours apart, and the collision is not theoretical: as the code below shows, at least one common runtime resolves the bare string BST to Bangladesh.
Reference table
Offsets below were computed against the listed IANA zone at the January and July 2026 reference instants.
| Abbreviation | Commonly means | UTC offset | Computed from |
|---|---|---|---|
| UTC | Coordinated Universal Time | UTC+00:00 | UTC |
| GMT | Greenwich Mean Time | UTC+00:00 | Europe/London, January |
| BST | British Summer Time | UTC+01:00 | Europe/London, July |
| BST | Bangladesh Standard Time | UTC+06:00 | Asia/Dhaka, year-round |
| EST | Eastern Standard Time (US) | UTC−05:00 | America/New_York, January |
| EDT | Eastern Daylight Time (US) | UTC−04:00 | America/New_York, July |
| CST | Central Standard Time (US) | UTC−06:00 | America/Chicago, January |
| CDT | Central Daylight Time (US) | UTC−05:00 | America/Chicago, July |
| CST | China Standard Time | UTC+08:00 | Asia/Shanghai, year-round |
| CST | Cuba Standard Time | UTC−05:00 | America/Havana, January |
| MST | Mountain Standard Time | UTC−07:00 | America/Denver, January |
| MDT | Mountain Daylight Time | UTC−06:00 | America/Denver, July |
| PST | Pacific Standard Time | UTC−08:00 | America/Los_Angeles, January |
| PDT | Pacific Daylight Time | UTC−07:00 | America/Los_Angeles, July |
| CET | Central European Time | UTC+01:00 | Europe/Paris, January |
| CEST | Central European Summer Time | UTC+02:00 | Europe/Paris, July |
| IST | India Standard Time | UTC+05:30 | Asia/Kolkata, year-round |
| IST | Israel Standard Time | UTC+02:00 | Asia/Jerusalem, January |
| IST | Irish Standard Time | UTC+01:00 | Europe/Dublin, July |
| JST | Japan Standard Time | UTC+09:00 | Asia/Tokyo, year-round |
| AEST | Australian Eastern Standard Time | UTC+10:00 | Australia/Sydney, July |
| AEDT | Australian Eastern Daylight Time | UTC+11:00 | Australia/Sydney, January |
Two entries deserve a second look. America/Phoenix computes to UTC−07:00 in both January and July: Arizona sits at the Mountain offset but does not observe daylight saving, so “MST” is correct there year-round while it is wrong in Denver for eight months of the year. And Australia’s eastern seaboard is frequently written as plain “EST” in local usage, at UTC+10:00 — the same three letters that mean UTC−05:00 in North America, a 15-hour gap.
Which abbreviations have no unambiguous mapping
These have no single correct IANA zone, and no code should ever try to resolve them:
- IST — India (+05:30), Israel (+02:00), Ireland (+01:00)
- CST — US Central (−06:00), China (+08:00), Cuba (−05:00)
- CDT — US Central Daylight (−05:00), Cuba Daylight (−04:00)
- BST — British Summer (+01:00), Bangladesh (+06:00)
- EST — North American Eastern (−05:00), Australian Eastern in local usage (+10:00)
The remainder in the table — UTC, GMT, JST, the CET/CEST pair, the US Pacific and Mountain pairs — are in practice read the way you expect. That is a convention, not a guarantee, and it does not make them identifiers. A machine still cannot derive a DST rule from the letters.
IANA identifiers are the reliable form
An IANA identifier names a place, not an offset: America/New_York, Europe/London, Asia/Kolkata. The Region/City form is unique by construction, and — this is the part abbreviations can never do — each identifier carries the zone’s complete offset history, including every daylight saving transition and every rule change a government has made. Ask for the offset of America/New_York at a specific instant and you get the offset that was actually in force at that instant.
Region/City — the tz database resolves the rules, you never do
https://www.iana.org/time-zones
America/New_York Asia/Kolkata Australia/Sydney
Europe/London Asia/Shanghai America/ChicagoHow an identifier encodes DST history
America/New_York in 2026, computed across its two transition instants:
| Instant (UTC) | Local time | Offset |
|---|---|---|
| 2026-03-08T06:59Z | 01:59 | UTC−05:00 |
| 2026-03-08T07:00Z | 03:00 | UTC−04:00 |
| 2026-11-01T05:59Z | 01:59 | UTC−04:00 |
| 2026-11-01T06:00Z | 01:00 | UTC−05:00 |
Local time jumps from 01:59 straight to 03:00 in March — the 02:00 hour does not exist that day — and 01:00 occurs twice in November. Both facts fall out of the identifier automatically. An abbreviation stapled to a local time carries none of it.
Southern-hemisphere zones invert the pattern. Australia/Sydney computes to UTC+11:00 (AEDT) in January and UTC+10:00 (AEST) in July, moving to +11:00 on October 4, 2026 while America/New_York does not fall back until November 1. In those four weeks the New York–Sydney gap goes 14 hours, then 15, then 16. A recurring meeting pinned to abbreviations breaks twice; a recurring meeting pinned to two IANA zones does not. epochkit’s timezone converter shows one instant across up to six IANA zones at once, which is the fastest way to see a shift like that before it bites.
The EST-vs-EDT trap
The most common abbreviation bug in English-language scheduling is writing “EST” in July. New York is on EDT — UTC−04:00 — from March 8 to November 1 in 2026, so “EST” is literally wrong for roughly eight months of the year, yet it is the form most people type all year round.
Usually a human reader silently corrects it. Code does not:
// Passing an abbreviation as a time zone: results are runtime-dependent.
// tz database: https://www.iana.org/time-zones
new Date("Jul 15 2026 12:00:00 EST").toISOString();
// "2026-07-15T17:00:00.000Z"
// EST applied as a fixed UTC−05:00 — one hour off the intended 12:00 EDT (16:00Z)The runtime did not “know” that New York was on EDT that day, because the string it was handed does not name New York. It names an offset — and the tz database does contain EST, MST, and HST as legacy fixed-offset zones that never observe daylight saving. Ask for EST and you get −05:00 in July, silently, forever.
The CST trap in scheduling and log parsing
Two failures, one abbreviation.
Scheduling. “Standup at 09:00 CST” resolves to 2026-07-15T14:00:00Z if CST means Chicago, and 2026-07-15T01:00:00Z if it means Shanghai. Both are plausible readings on a team that spans both. Nobody arrives late; half the team arrives on a different day.
Log parsing. A log line ending in CST cannot be parsed correctly, only guessed at. Here is what one widely used runtime actually does when handed abbreviations:
new Date("Jan 15 2026 12:00:00 CST").toISOString();
// "2026-01-15T18:00:00.000Z" — read as US Central (−06:00). Never China.
new Date("Jan 15 2026 12:00:00 IST"); // Invalid Date
new Date("Jan 15 2026 12:00:00 JST"); // Invalid DateCST is silently assumed to be American. IST and JST are not recognized at all — the parse fails outright, and code that does not check for Invalid Date propagates a NaN timestamp into whatever it touches next. Non-ISO date parsing is implementation-defined, so a different runtime may make different guesses on the same string.
Passing abbreviations as zone identifiers is no safer. Computed at the same two reference instants:
| Passed as a time zone | January | July | What the writer probably meant |
|---|---|---|---|
EST | UTC−05:00 | UTC−05:00 | America/New_York (−05:00 / −04:00) |
MST | UTC−07:00 | UTC−07:00 | America/Denver (−07:00 / −06:00) |
CST | UTC−06:00 | UTC−05:00 | America/Chicago — or Asia/Shanghai (+08:00) |
PST | UTC−08:00 | UTC−07:00 | America/Los_Angeles |
IST | UTC+05:30 | UTC+05:30 | India — but Israel and Ireland write IST too |
BST | UTC+06:00 | UTC+06:00 | British Summer Time (+01:00) — this is Bangladesh |
JST | UTC+09:00 | UTC+09:00 | Asia/Tokyo |
Note the inconsistency: EST never observes DST, but CST and PST do. And BST resolves to UTC+06:00 — Bangladesh — for anyone who meant London in summer. These strings are accepted without error and return a plausible-looking number, which is the worst possible failure mode.
While you are avoiding abbreviations, avoid the Etc/GMT family too, or read the sign carefully:
// POSIX sign convention — inverted from what the name suggests
"Etc/GMT+5"; // UTC−05:00
"Etc/GMT-5"; // UTC+05:00Practical guidance
Scheduling across teams
Anchor every announcement to an instant, not a label. Write “16:00 UTC” and let each reader convert, or write the offset explicitly — “16:00 UTC (12:00 New York, 21:30 Kolkata)” — so there is nothing to interpret. Where the platform can render viewer-local time from a single timestamp, use it: Slack’s date formatting syntax and Discord’s <t:...> tokens both do this, and both remove the ambiguity at the source rather than papering over it. If you must include an abbreviation because your audience expects one, put the UTC offset beside it: “9:00 AM CST (UTC−06:00)” is unambiguous; “9:00 AM CST” is not.
Storing times in systems
For a past or present instant, store UTC. A Unix timestamp or an ISO 8601 string with an explicit offset both pin the moment exactly; the ISO 8601 vs Unix comparison covers which suits which column.
For a future local event — a 09:00 meeting six months out, a nightly job that must run at 02:00 local — store the IANA identifier alongside the local wall time. An offset alone is not enough: governments change daylight saving rules, the tz database is updated when they do, and an event stored as -05:00 will fire at the wrong local hour if the rule changes before the date arrives. An event stored as America/New_York plus 09:00 re-derives the correct offset every time.
And never store the abbreviation. It is a rendering detail, produced at display time from the identifier and the instant. Derive it on the way out; never accept it on the way in.
Related tools
Use epochkit’s timezone converter to see one instant across up to six IANA zones side by side, with daylight saving applied automatically from the tz database. To pin an instant in the first place, the Unix timestamp converter converts in both directions.
How we create this content: Our guides are drafted with the help of AI tools, then reviewed, fact-checked against the relevant specifications (POSIX, RFC 3339, crontab(5), or platform docs), and tested in epochkit's own tools by a human before publishing. We update them when specs or platform behavior change. Spotted something wrong? Email contact@epochkit.dev — we'll fix it.