Time zone abbreviations, the reference every scheduler needs

Quick answer

If you are here to settle an argument, here is the short version. Time zone abbreviations are not unique. "IST" can mean India, Ireland, or Israel. "CST" can mean US Central, Cuba, or China. "BST" can mean British Summer or Bangladesh Standard. The only reliably unambiguous identifiers are the IANA time zone names, strings like America/New_York, Europe/London, Asia/Kolkata, and the UTC offset itself (UTC+5:30, UTC-5, UTC+9).

If you write code, store IANA. If you write calendar invites, the IANA name is what your invite already uses under the hood, your client just shows you the abbreviation. If you write emails, write the time once in your zone and once in UTC with an explicit offset, and stop using abbreviations entirely. The rest of this guide is the reference for when you have to read somebody else's abbreviation and figure out what they meant.

North American zones

North America runs on a stack of six main civil zones, each with a standard (winter) and daylight (summer) variant. The continent observes DST on the same schedule across the US and most of Canada, second Sunday of March forward, first Sunday of November back, which is the reason the abbreviations stay readable for an audience that is already on the continent. They become unreadable the moment you cross an ocean.

For the side-by-side hour grid showing exactly how these line up against London or Tokyo, our EST vs PST comparison is the fastest reference for the two North American zones most teams care about.

European zones

Europe has three main civil zones, Western, Central, and Eastern, plus Moscow, plus a handful of outliers. The whole EU shifts DST together on the last Sunday of March and the last Sunday of October, which is one Sunday later than the US in the spring and one Sunday earlier in the autumn. That offset creates the famous four-week-a-year window where transatlantic meetings silently misfire.

If you are coordinating between London and the continent, the practical thing to remember is that "BST is one hour ahead of GMT" and "CET is one hour ahead of GMT", so for half the year, BST and CET are the same wall-clock time and people say "London time" when they mean "Berlin time" and nobody minds. In winter that breaks, GMT is back, and London is one hour behind Berlin.

Asian zones

Asia is where the abbreviation system breaks hardest. Two of the most common three-letter codes, IST and CST, refer to entirely different countries depending on the audience, and the offsets are nowhere near each other. India and China are also two of the largest English-speaking professional populations in the world, so the collisions actually happen in everyday business communication.

If you work with India or China and you receive a "3 PM IST" or "10 AM CST" email, do not assume. Ask, or look at the sender's domain and the message metadata. Most enterprise mail clients embed the sender's time zone in the message headers per RFC 2822, when there is a conflict between the body text and the header, trust the header.

Oceania

Australia and New Zealand have an unusually complicated DST story for the size of their populations. The eastern Australian states observe DST; Queensland does not; Western Australia does not; the territories have their own rules. New Zealand observes DST on a schedule that does not match Australia. The result is that AEST/AEDT and NZST/NZDT swing relative to each other through the year.

The ambiguous abbreviations table

This is the table to bookmark. Every three-letter code below has at least two legitimate meanings in current use. The "safe to use" column is opinionated, it is the one most readers will assume given the global English-speaking business population. The "canonical IANA" column is the answer if you want to be unambiguous.

There are more. The full IANA database lists hundreds of historical abbreviations, many no longer used but still occasionally surfaced by legacy systems and old Java code. If you ever inherit a system that does its own date parsing from abbreviations, throw it out, there is no parser in the world that gets all of these right without a country context.

Why IANA names beat abbreviations, every time

The IANA time zone database (also called the tz database, tzdata, or the Olson database) is the canonical reference for time zone rules. Every major operating system, programming language, and calendar system uses it. It contains entries like America/New_York, Europe/London, Asia/Kolkata, Australia/Sydney, and a long tail of historical and political curiosities like America/Indiana/Knox (one Indiana county on Central time while its neighbours observe Eastern) and America/North_Dakota/Beulah (a town that switched zones in 2010).

IANA names are unambiguous because they encode the political authority that decides the rules, not the rules themselves. America/New_York means "whatever time zone New York is observing right now, including future DST transitions, leap seconds, and any law the state passes next year". If the US abolishes DST tomorrow, every system using America/New_York picks up the change as soon as it gets a tzdata update. Every system using "EST" as a fixed offset breaks.

The mess with abbreviations like IST is a downstream symptom of this design. Asia/Kolkata, Europe/Dublin, and Asia/Jerusalem are three entirely separate IANA entries. Their governments make independent decisions about offsets and DST. The fact that all three display as "IST" in a US-locale system is an artefact of English naming conventions, not the underlying database. Switch your locale to the local country and the abbreviation often disappears in favour of something native.

If you write date strings into JSON, follow RFC 3339 / ISO 8601: 2026-05-28T15:00:00-05:00 is unambiguous and parseable everywhere. If you need to preserve the zone for future recurrence (a meeting that should always happen at 9 AM New York, even after DST changes), store both: the timestamp and the IANA name. Calendar invites in iCalendar format (RFC 5545) already do this with their VTIMEZONE blocks. Trust the standard and stop trying to roll your own.

The same principle applies to email. RFC 822 and its successor RFC 2822 require Date headers to use a numeric offset like -0500 or a small set of named US zones for historical reasons. Three-letter abbreviations outside that set are explicitly obsolete. Modern mail clients respect this; manual "3 PM EST" in body text does not.

Military and aviation zones: A through Z

If you have ever seen a time written as "1430Z" on a flight plan or a NATO operations order, you have seen the military zone system. It is a single-letter code per hourly offset from UTC, used because it is unambiguous in radio transmissions and easy to write in a hurry.

The system runs A through Z with one exclusion. Z is Zulu, which is UTC+0, the same as UTC and GMT. The letters A through M (excluding J) cover offsets east of UTC, A being +1 and M being +12. N through Y cover offsets west of UTC, N being -1 and Y being -12. J is intentionally skipped because in NATO phonetic it sounds too similar to other letters; some sources say it is reserved for "local" time.

In civilian life you will mostly only see Z, used in software logs ( 2026-05-28T14:30:00Z) as a shorthand for UTC. ISO 8601 explicitly allows the trailing Z as equivalent to +00:00, and RFC 3339 inherits the convention. If you log timestamps in any backend system, log them in Z. Do not store local time and a separate offset string, the timestamp will rot the first time DST shifts.

Tools

Once you have decided to ignore abbreviations and use IANA, the remaining problem is reading other people's. The tools below are the ones we use ourselves.

For one-off conversions, the time zone converter accepts both abbreviations and IANA names. Type "IST" and it asks which one. Type Asia/Kolkata and it just works.

For the side-by-side hour grids most teams need on a recurring basis, the comparison pages are the fastest reference: EST vs PST for the two North American zones, GMT vs UTC for the prime-meridian question that comes up at least once a quarter, and the world clock for a real-time view of every city you care about.

If you are still scheduling meetings manually across more than two zones, you are paying a tax. The smarter calendar tools in this category automate the IANA-aware resolution and stop the abbreviation game from biting you.

FAQ