IST, CST, BST: ambiguous time zone abbreviations explained

An email arrives: "Can we talk at 3:00 PM IST on Wednesday, July 15?" You're in New York. If the writer means India, the call is at 5:30 AM for you. If they mean Ireland, it's at 10:00 AM. Same three letters, four and a half hours apart.

That's the trouble with ambiguous time zone abbreviations. IST, CST, BST, GST and several others each stand for more than one place, and nothing in the letters tells you which. This guide explains why they collide, what each one can mean, how to tell which one a writer intended, and what to write instead. Every offset and daylight saving date below was checked against the IANA time zone database.

Why time zone abbreviations collide

No authority hands out unique time zone abbreviations. They're informal, built from the initials of English names, and plenty of those names start the same way:

• India, Irish and Israel Standard Time all make IST.
• Central, China and Cuba Standard Time all make CST.
• British Summer Time and Bangladesh Standard Time both make BST.

The main public reference for time zone rules is the IANA time zone database, also called tzdb. It deliberately doesn't identify zones by abbreviation. It names them by region and city, such as America/Chicago and Asia/Kolkata. Its theory document points out that CST and IST each mean different things in different countries. For many zones, tzdb doesn't record a letter abbreviation at all and uses a numeric one: Bangladesh's zone, Asia/Dhaka, is written +06.

Software adds another layer, because the label you see depends on language settings. In the Unicode ICU data used by Node.js 22 (ICU 78):

• India's zone displays as "IST" in English (India), but as "GMT+5:30" in English (US).
• London in July displays as "BST" in English (UK), but as "GMT+1" in English (US).
• Dublin in July displays as "IST" in English (Ireland).

So an abbreviation tells you as much about the writer's habits and settings as about the place. Two people can look at the same moment and see different letters.

Ambiguous time zone abbreviations: a reference table

Use this table when you meet an abbreviation you can't place. Offsets are for standard time unless noted. Daylight saving dates are for 2026.

The dates in the table come from NIST for the United States, GOV.UK for the UK, and the IANA time zone database for the rest.

IST: India, Ireland or Israel?

Start with the season, because two of the three meanings only exist for part of the year.

• India Standard Time is UTC+5:30 all year. India doesn't use daylight saving time.
• Irish Standard Time is Ireland's summer clock, UTC+1. In 2026 it runs from March 29 to October 25. Irish law treats UTC+1 as the standard and the GMT winter months as the exception, which is why the summer clock is the "standard" one.
• Israel Standard Time is UTC+2 and applies outside summer. From March 27 to October 25, 2026, Israel is on Israel Daylight Time (IDT), UTC+3.

So in July, "IST" means India or Ireland. In January, it means India or Israel. In 2026 the Irish and Israeli versions overlap for only about two hours, overnight into October 25.

Here's what "3:00 PM IST" means for readers in New York and London, depending on the reading:

To work out which one the writer meant, look for:

• A city in the signature, or a phone number with a country code.
• Other times in the thread. If they've written "Irish time" or "India time" before, you have your answer.
• Whether the time is plausible. A 3:00 PM call from someone who mentions their Bengaluru office is India.

If the clues run out, ask. "Just to confirm, is that 3:00 PM India time?" costs one line and saves a missed call.

CST: Chicago, Beijing or Havana?

The readings of CST can be 14 hours apart. Take "9:00 AM CST" on Wednesday, November 18, 2026. If the writer meant Chicago, it's 11:00 PM that evening in Beijing. If they meant Beijing, it's 7:00 PM on Tuesday evening in Chicago.

• North American Central Time is CST (UTC−6) in winter and CDT (UTC−5) from March 8 to November 1, 2026. A US writer who puts "CST" on a July date almost always means Central Time, which is UTC−5 then.
• Some Central zones never change. Most of Saskatchewan and central Mexico, including Mexico City, stay on UTC−6 all year, so "CST" is correct there in July.
• China Standard Time, listed in tzdb as Beijing Time, is UTC+8 all year. The database also records a separate Xinjiang Time (Asia/Urumqi, UTC+6).
• Cuba Standard Time is UTC−5. Cuba moves to Cuba Daylight Time (UTC−4) on the same dates as the US in 2026, but around midnight local time rather than at 2:00 AM.

China doesn't use daylight saving time, so the gap to Chicago is 14 hours in winter and 13 hours from March 8 to November 1. Either way, a misread CST is off by more than half a day.

BST vs GMT

UK clocks show Greenwich Mean Time (GMT, UTC+0) in winter and British Summer Time (BST, UTC+1) in summer. In 2026, BST runs from March 29 to October 25, according to GOV.UK. Ireland keeps the same clock times as the UK all year but calls its summer time Irish Standard Time.

Two mistakes come up again and again:

• Writing GMT in summer. "Call at 10:00 GMT" on July 15, read literally, is 11:00 AM on London clocks. Most writers mean UK time, so it's worth confirming.
• Assuming BST is British. Bangladesh Standard Time has the same initials. It's UTC+6 all year, so 3:00 PM in Dhaka is 10:00 AM in London in July and 9:00 AM in winter.

Is BST the same as GMT+1? As an offset, yes. But "GMT+1" written in January describes somewhere like Berlin or Lagos, not London, because the UK is back on GMT by then.

EST vs EDT: standard and daylight names

North American abbreviations come in pairs. The S stands for standard (winter) time and the D for daylight (summer) time.

In 2026, daylight time runs from March 8 to November 1, according to NIST. The next switch to daylight time is March 14, 2027.

The generic names are the safe choice. "Pacific Time" means whatever clocks in Los Angeles show on that date. "PST" on a July date is, strictly, an hour off, though the writer almost always means Pacific Time. Arizona is the exception: most of the state stays on Mountain Standard Time all year, so "MST" is correct there in July.

The same standard-and-summer pattern shows up elsewhere:

• Central Europe: CET (UTC+1) in winter and CEST (UTC+2) from March 29 to October 25, 2026, set by Directive 2000/84/EC.
• Sydney: AEST (UTC+10) in winter and AEDT (UTC+11) from October 4, 2026 to April 4, 2027, according to the NSW Government.
• New Zealand: NZST (UTC+12) in winter and NZDT (UTC+13) from September 27, 2026 to April 4, 2027, according to the New Zealand Government.

Many places don't switch at all in 2026: India, China, Singapore, Japan, Bangladesh, the United Arab Emirates and Indonesia keep one offset all year, as do Queensland and Western Australia.

Offsets vs names: when "UTC+1" misleads

A UTC offset such as UTC+5:30 is precise for a single moment. There's only one UTC+5:30, so offsets are a good way to pin down a one-off time: "15:00 UTC+1 on July 15."

But an offset isn't a place. It describes what a clock shows on one date, not what it will show next month:

• UTC−5 is New York in winter, Chicago in summer and Bogotá all year.
• UTC+1 is London and Dublin in summer, Berlin in winter and Lagos all year.

That makes offsets risky for anything that repeats. A weekly meeting written as "10:00 UTC+1" matches 10:00 AM in London until October 25, 2026. After the UK falls back, the same offset is 9:00 AM in London, and nobody can tell whether you meant the offset or the London clock.

Two more traps:

• "GMT" often means UK time. "GMT+1" and "UTC+1" are the same offset, but plain "GMT" in a British email may mean whatever London clocks show, which is UTC+1 in summer.
• Technical ids flip the sign. In the tz database, Etc/GMT+5 is five hours behind UTC, the same as UTC−5. The tzdb source notes that this follows the POSIX convention, which many people don't expect.

"2 pm Indonesia time": WIB, WITA and WIT

Indonesia spans three time zones, and none of them uses daylight saving time.

Jakarta, the capital, is on WIB, so it's the natural first guess for "2 pm Indonesia time". But a colleague in Bali is an hour ahead of Jakarta, and one in Jayapura is two hours ahead. If the meeting matters, ask for the city.

What to write instead

Here are the unambiguous options, from most to least reader-friendly:

1. A city with "time." "3:00 PM Dublin time" survives daylight saving changes and needs no decoding.
2. A full zone name. "India Standard Time", "Eastern Time", "China Standard Time". Prefer generic names such as Eastern Time over EST or EDT, unless you mean that exact offset.
3. A UTC offset, for one-off moments. "14:00 UTC on July 15." Add a city if people will act on it locally.
4. An IANA zone id, for anything technical. Store Europe/Dublin or Asia/Kolkata in systems, never an abbreviation, and avoid Etc/GMT ids.

For formats, signatures and templates you can copy, see how to write time zones in an email.

A time zone style guide for your team

Abbreviation mix-ups are a team habit, so fix them as a team. Copy these rules into your handbook:

1. Write the city first: "3:00 PM London time." If you add an abbreviation, put it in brackets after the city.
2. Never use IST, CST, BST, GST, AST or SST on their own.
3. For North America, write Eastern, Central, Mountain or Pacific Time. Use EST, EDT and the rest only when you mean that exact offset.
4. Don't write GMT for UK time between late March and late October. Write "UK time" or "London time."
5. Add the weekday and date whenever a time crosses midnight for someone.
6. Use one clock format per message, 12-hour or 24-hour.
7. Add UTC for global one-off events: "14:00 UTC on July 15 (3:00 PM London, 10:00 AM New York)."
8. For recurring meetings, name the anchor city and flag the weeks when clocks change. Our guide to scheduling meetings across time zones lists the 2026 dates.
9. Put your city in your email signature, for example "Priya, Bengaluru (India time)." It helps readers, and tools that suggest a time zone from a signature, Timehint included.
10. In code, databases and spreadsheets, store IANA ids and UTC timestamps, never abbreviations.

Frequently asked questions