How to read a time zone list without getting it wrong
A list of time zones looks like reference material until you actually need to pick one. Then the questions start: why are there three entries at the same offset, what is a zone identifier for, and which of these is the one an API expects.
An identifier is not the same thing as an offset
Every entry here is an IANA zone identifier of the form Area/Location — Europe/Berlin, America/Argentina/Buenos_Aires, Asia/Kolkata. The identifier names a region and a set of rules. The number beside it, such as UTC+02:00, is only what those rules produce today.
The distinction matters the moment a zone changes. Europe/Berlin has been UTC+01:00 in winter and UTC+02:00 in summer for years, while the identifier has not changed once. A timestamp stored with its identifier stays unambiguous forever; one stored with a bare offset does not.
Why the abbreviations will mislead you
CST is Central Standard Time in North America, China Standard Time in Beijing, and Cuba Standard Time in Havana. IST is India, Ireland and Israel. BST is British Summer Time and Bangladesh Standard Time.
Abbreviations are not unique, are not standardised, and are not part of any identifier. Sorting a table by abbreviation puts cities eleven hours apart in adjacent rows, which is how scheduling mistakes get made.
The Etc/GMT sign trap
The fixed-offset zones named Etc/GMT+5 and Etc/GMT-5 invert the sign you would expect: Etc/GMT+5 is five hours behind UTC, in other words UTC−05:00. The convention comes from the POSIX TZ variable and has been preserved for compatibility rather than for clarity.
If you only need a constant offset, write the offset and skip the identifier. Reach for an Etc/GMT name only when something downstream insists on an IANA string.
Same offset, different rules
Two cities can share an offset all year and still require different identifiers, because the rules behind them differ. Asia/Shanghai and Asia/Singapore both sit at UTC+08:00 with no daylight saving, yet they are separate entries with separate histories.
This is where a plausible-looking shortcut fails. Building a calendar on the wrong identifier produces correct times for today and wrong ones for a date five years ago, and the error only shows up when someone checks a historical record.
Searching and filtering the list
The search box matches against the identifier, so a city name works whenever it appears inside one: “Shanghai” finds Asia/Shanghai, “Buenos” finds America/Argentina/Buenos_Aires. Country names and offsets are not searchable.
The region buttons narrow the list to a single top-level area — America, Europe, Asia, Africa, Australia, Pacific, Atlantic, Indian, Arctic, Antarctica. Recent selections are stored in your browser and are never sent to a server.