Why time zones exist
For most of human history, the answer to "what time is it?" was a local one. Every town set its clocks by the sun. Noon was when the sun was highest overhead, and noon in one town was a few minutes before or after noon in the town fifty miles east. As long as travel between the two took a day on horseback, the discrepancy did not matter. Two clocks in two villages could disagree by ten minutes and the world would not notice.
The railway broke that. In Britain in the 1840s, the Great Western Railway started running trains between London and Bristol on a single coordinated timetable, and the only way to keep the timetable readable was to pick one clock and force every station along the line to use it. "Railway time", set by Greenwich, slowly displaced local mean time across the British network through the 1840s and 1850s, and by 1855 most public clocks in Britain were showing Greenwich. The same pressure spread to North America in the 1880s, where the explosive growth of the transcontinental railroad system meant that hundreds of local clocks were now competing with the schedule of a single train moving across them. The Pennsylvania Railroad alone ran on six different official times.
The telegraph turned a national problem into an international one. Once cables could carry a coordinated time signal across oceans, the question of "what time is it in Liverpool?" stopped being academic for a ship captain in New York. In October 1884, twenty-five nations sent delegates to the International Meridian Conference in Washington DC, where they agreed to adopt the Greenwich Meridian as the prime meridian of the world and to count longitude east and west from there. The conference did not actually create civil time zones — it created the geometric framework for them. The 24 one-hour zones we now colloquially describe as "the time zones" are the obvious downstream consequence: divide the globe into 24 wedges of 15 degrees, and you get one hour of mean solar time per wedge.
The 24-zone model was always a simplification. Even in 1884 the delegates knew that political and geographic reality would not respect 15-degree slices, and within twenty years the first half-hour offsets had appeared. By the time Sandford Fleming, the Canadian engineer credited with much of the early standardization work, was finalizing his proposals, the world had already started carving the wedges into shapes that matched countries instead of meridians. That is the world we still live in.
The IANA tz database
Every modern operating system, every major programming language runtime, and every serious calendar application ultimately defers to a single file collection called the IANA Time Zone Database. It is also called the tz database, tzdata, the zoneinfo database, or the Olson database after Arthur David Olson, who started maintaining it in the 1980s while working at the US National Institutes of Health. Today it is coordinated by Paul Eggert at UCLA and a small group of contributors, with formal stewardship by IANA and dispute resolution under RFC 6557.
The database is a set of text source files describing every civil time zone rule in current and historical use, plus a tool called zic (the zone information compiler) that turns those text files into binary zoneinfo blobs that operating systems can read at runtime. The source files include zone1970.tab, which is the master list of zone identifiers and the country codes they belong to; one file per region (africa, asia, europe, northamerica, and so on) containing the actual transition rules; and leapseconds, which records every UTC leap second since 1972. Releases are versioned by year and letter — 2026a, 2026b, and so on — and ship two or three times a year, sometimes more when a government makes a surprise change.
The reason every OS depends on it is that the database is the only canonical source of truth for time zone rules. Governments change DST rules with little notice. Border changes redraw which IANA zone a particular town belongs to. Historical records are corrected as researchers dig up old laws and almanacs. Without a coordinated database, every OS would have to track every change independently, and they would fall out of sync within a year. With tzdata, every Linux distribution, every macOS release, every Windows ICU build, every Java JRE, every Python zoneinfo module, and every modern browser pulls the same source and applies the same rules. When Türkiye made a surprise announcement in 2016 that it was abandoning DST permanently, every tzdata-aware system on Earth was updated within weeks.
For more on how programs are expected to consume the database in their date arithmetic, see our companion piece on the date and time format style guide — it covers the storage formats that pair sensibly with IANA names.
UTC vs GMT
For most purposes the two are interchangeable. Both refer to the time at the prime meridian. Both are written as "+00:00" in an ISO 8601 offset. Both are what your phone shows when you set it to "London time" in January. If you are scheduling a call, deciding whether to write "3 PM UTC" or "3 PM GMT" is purely a question of audience: pick the one your recipient is more likely to read correctly.
The technical difference matters if you write aviation, telecoms, or financial settlement software, and rarely otherwise. UTC, defined by the Bureau International des Poids et Mesures and disseminated by a network of atomic-clock laboratories around the world, is a coordinated reference adjusted by occasional leap seconds to stay within 0.9 seconds of mean solar time at Greenwich. GMT is the historical mean solar time itself, defined by the position of the Sun as observed at the Royal Observatory. UTC is the standard you build a GPS satellite to. GMT is the standard the BBC World Service still announces at the top of the hour.
The rule of thumb: use UTC for code, use GMT for British radio. If you ever find yourself caring about the 0.9-second difference, you are either writing flight management software or you have already misread the spec.
Half-hour and 45-minute zones
The textbook 24-zone model says that every civil time zone should be a whole number of hours away from UTC. The real world disagrees. A meaningful fraction of the world's population lives in zones that are offset by 30 minutes or 45 minutes from a neighbour, and most of them are not historical accidents — they are deliberate political and geographic compromises.
India (Asia/Kolkata, UTC+5:30) is the largest example by population. The country spans roughly 30 degrees of longitude — enough to justify two whole-hour zones — but uses a single civil time for administrative cohesion. The midpoint of British India fell almost exactly between the +5 and +6 meridians, so the colonial government in the early 1900s picked the average. Sri Lanka uses the same +5:30 offset. The convention has held for over a century and now defines the working day for one of the largest software industries in the world.
Newfoundland (America/St_Johns, UTC-3:30) is the half-hour offset most Canadians never think about. The island sits east of mainland Canada's Atlantic zone but west of the next hourly meridian, so St. John's runs 30 minutes ahead of Halifax. There is also a corresponding daylight saving offset of UTC-2:30 in the summer. Software that assumes every Canadian zone differs by a whole number of hours from Toronto silently mis-schedules every Newfoundland meeting.
Nepal (Asia/Kathmandu, UTC+5:45) is the most unusual offset in current civil use. The country sits between India (+5:30) and Bangladesh (+6:00) and chose 5:45 as a deliberate national statement of distinction from the much larger Indian neighbour. The offset has held since 1986. The Chatham Islands (Pacific/Chatham, UTC+12:45 / +13:45) in New Zealand are the other 45-minute zone, also chosen as a compromise between two whole-hour wedges. There are roughly 600 permanent residents of the Chatham Islands and yet the zone has held since 1957, gets dutifully tracked by tzdata, and breaks code that assumes offsets are always a multiple of 30 minutes.
If you are writing UI for offset selection, do not show a dropdown of whole hours. If you are writing scheduling logic, do not subtract offsets in integers of hours. The time zone converter handles every offset in the IANA database, including the 45-minute ones, because the underlying data does the work — that is the whole point of using tzdata.
DST: the messy middle
The case for daylight saving time has a clean origin story and a much messier track record. George Hudson, a New Zealand entomologist, proposed a two-hour shift in 1895 because he wanted more daylight after work for collecting insects. William Willett, a London builder, proposed a graduated 80-minute shift in 1907 because he wanted to play golf later in the evening. Neither proposal was adopted in its original form. What actually drove DST into law was the First World War: Germany and Austria-Hungary introduced it in April 1916 to save fuel for the war effort, the United Kingdom followed in May, and most of the rest of Europe and North America followed within two years. The original justification was energy conservation, and it has remained the official justification ever since.
The evidence for the energy benefit has not aged well. Modern studies — the large ones consistently cited are the 2008 US Department of Energy report and the 2007 Indiana natural experiment by Kotchen and Grant — find the energy savings somewhere between negligible and slightly negative, depending on the climate. The displacement effect is the killer: people use less lighting in the evening but more air conditioning, more heating in the dark morning, and more fuel commuting in the still-dark hours either side of the shift. The cardiovascular research is also persistent: rates of heart attack, stroke, and workplace injury reliably spike in the week after the spring forward, and reliably drop after the fall back. The cost-benefit argument for DST has been net-negative for at least a decade, and most policy researchers now treat the practice as inertia rather than evidence.
Abolition is therefore on the table almost everywhere. Russia abolished DST in 2011, dropping back to permanent standard time after a brief experiment with permanent summer time that proved unpopular. Türkiye abolished DST in 2016 and stayed on permanent summer time (UTC+3) ever since. Mexico abolished DST for most of the country in October 2022, with a narrow border zone retained for cross-border commerce with the US. The European Union voted in 2018 to end seasonal time changes, then could not agree on whether the permanent baseline should be summer or winter, and the directive has been in legislative limbo ever since. In the United States, the Sunshine Protection Act passed the Senate in 2022 and then died in the House without a vote. As of 2026, the politics has not shifted.
Until the politics resolves, the practical effect is that DST keeps becoming more fragmented, not less. Every country abolishes on its own timeline and lands on its own baseline. The DST tracker is the live view of every transition over the next twelve months in every zone that still observes it, and the DST 2026 survival guide is the dated walkthrough for this year specifically.
The most confusing zones
Three-letter time zone abbreviations look authoritative and are not. Several of them refer to two or three different zones depending on the audience, and the conflicts happen in the actual day-to-day mail of any company with offices in more than one continent.
IST is the worst. It means India Standard Time (UTC+5:30) to an audience in Mumbai, Israel Standard Time (UTC+2) to an audience in Tel Aviv, and Irish Standard Time (UTC+1, summer only) to an audience in Dublin. "3 PM IST" in an email to a mixed audience is an invitation to at least one no-show.
CST is almost as bad. It means North American Central Standard Time (UTC-6) to an audience in Chicago, China Standard Time (UTC+8) to an audience in Beijing, and Cuba Standard Time (UTC-5) to an audience in Havana. The offsets are fourteen hours apart at the extremes, and "9 AM CST" is ambiguous to anyone who works with both a US and a Chinese partner.
BST is the British case. It is British Summer Time (UTC+1) for eight months of the year in London, and Bangladesh Standard Time (UTC+6) all year in Dhaka. AST is North American Atlantic Standard Time (UTC-4) to most of Canada, and Arabian Standard Time (UTC+3) to most of the Gulf. EST is the cleanest of the common ones — it unambiguously means North American Eastern Standard Time — but only if you also remember that for eight months a year the zone is actually on EDT (UTC-4) and writing "EST" in July is a small lie that mostly does not break anything but occasionally does.
The full reference is in our companion guide, time zone abbreviations — it lists every three-letter code in active business use, the offsets they map to, and the IANA names you should use instead.
Time zones in software
There is one rule that handles 90% of the time-zone bugs you will hit in practice: store timestamps as UTC, render in the user's local zone at display time. Every database row, every log line, every audit record, every event payload should record the instant in UTC. The conversion to local happens at the edge, in the client or the templating layer, the moment before a human sees the value.
The reason this works is that UTC is the only representation that is unambiguous in retrospect. "15:00 local" is meaningless without a zone qualifier. "15:00 +01:00" is meaningless if you do not know what zone that offset belongs to (an offset of +01:00 in March is BST, in November it is CET, the wall-clock conversion to UTC is the same but the political reality differs). "15:00 Europe/London" is unambiguous now but requires a tzdata lookup to interpret in the future. "14:00 UTC" is unambiguous now, in the future, and after any government changes its DST rules.
The exception is future events that recur on a wall-clock schedule. If you have a meeting at "9 AM London every Tuesday", storing only the UTC instant of the first occurrence is wrong — when London transitions to BST, the UTC instant of the next Tuesday at 9 AM London is now an hour earlier. For these cases, store both the UTC instant of the canonical occurrence and the IANA zone identifier, and let the calendar layer recompute future occurrences against the latest tzdata at read time. The iCalendar format (RFC 5545) does exactly this with its VTIMEZONE blocks; if you are writing a scheduler that interoperates with anything, follow the standard.
The full developer-side treatment is in the time format style guide. It covers when ISO 8601 wins over Unix epoch, what SQL TIMESTAMPTZ actually stores, and the anti-patterns that will burn you in production.
The Olson IDs your code uses
The IANA tzdb uses a consistent naming scheme for its zone identifiers. The form is generally Region/Locality, where the region is a coarse continent and the locality is a representative city. The canonical examples are America/New_York, Europe/London, Asia/Kolkata, Australia/Sydney, and Pacific/Auckland. The locality is conventionally a city that the zone is named for, not the largest city in the zone, though the two often coincide. The zone America/New_York covers most of the US East Coast, not just the city.
The naming is deliberate: it picks a representative locality rather than a country, because the zone rules belong to a polity smaller than a country in many cases. The United States has six primary zones in the tzdb, plus separate identifiers for Arizona (which does not observe DST), parts of Indiana (which were on a mix of Eastern and Central until 2006), and the Aleutian Islands. The identifier America/Indiana/Knox covers a single Indiana county that has been on Central time even though its neighbours observe Eastern. There is genuinely no shorter way to encode that fact.
The reason your code should use the locality form and not the abbreviation is that abbreviations are fixed offsets, and IANA names are rules. The string EST in a date library typically means the fixed UTC-5 offset, with no DST. The string America/New_York means whatever New York is observing at the moment of the timestamp, including future DST transitions and any law the state passes next year. Using EST in JavaScript with Intl.DateTimeFormat for a July date will produce a wall-clock value an hour off from what "New York time" actually is in July.
IANA also maintains a long list of aliases for historical names. The string US/Eastern is an alias for America/New_York; Asia/Calcutta is an alias for Asia/Kolkata; Europe/Kiev is an alias for Europe/Kyiv; and so on. Old code that uses the deprecated names will keep working — the aliases are preserved deliberately for backward compatibility — but new code should use the canonical form. The list of aliases lives in the backward file in the tzdata source distribution.
Updates flow through your operating system. On Linux this is typically through atzdata package shipped by the distribution; on macOS through the regular system updates; on Windows through Microsoft's separately released time zone updates plus the ICU library updates that ship with browsers and some runtimes. JVM updates ship their own copy of tzdata. The lag from an IANA release to your runtime can be anywhere from a few days to a few months depending on the platform, which is why systems that care about correctness often pull tzdata directly rather than trust the OS.
The future
The two large directions on the horizon are abolition of DST and, more rarely discussed, the proposal to abolish civil time zones altogether in favour of global UTC. The first is happening incrementally and unevenly. The second has been periodically proposed for decades — most recently in a 2017 paper by economists Steve Hanke and Richard Conn Henry, who argued for everyone on Earth using the same wall-clock time with local conventions about when the working day starts — and has gained no real political traction. The reason is obvious: most people care more about "is it 9 AM where I am" than "what number is the clock reading", and forcing every culture to renegotiate the meaning of "morning" is a much harder ask than getting governments to agree on a meridian.
Permanent DST has more political momentum and more inertia in the way. The United States Senate unanimously passed the Sunshine Protection Act in 2022, then the House let it die without a vote. The European Union voted in 2018 to end seasonal time changes by 2021, then never agreed on a permanent baseline. Mexico abolished it for most of the country in 2022. Türkiye and Russia did so a decade earlier. None of these decisions are coordinated and none use the same permanent baseline, which means that the practical near-term effect of "DST abolition" is more fragmented offsets, not fewer.
On the software side, the interesting trend is the rise of AI assistants that handle scheduling natively. The major AI labs — OpenAI, Anthropic, Google DeepMind — are all building agentic features that need to reason about time zones to schedule meetings, set reminders, and interact with calendars. That pressure is good for tzdata adoption: an agent that gets time-zone reasoning wrong embarrasses its vendor in an immediate, visible way. Expect to see the first wave of agent SDKs ship with tzdata-aware datetime primitives as a default, and expect the practice of "store local, hope DST works out" to become rarer the more autonomous tooling has to reason about it.
None of this is astrology. The technical pushback against global UTC is real, the political reality of DST abolition is incremental, and the trend in practical software is towards more rigorous handling of time-zone rules, not less. The world will still have time zones in 2050. They will still mostly be set by national governments. The IANA tzdb will still be the source of truth. Bet accordingly.
Tools Zeitful ships for this
Almost every tool on this site is downstream of the tzdata model — they wrap the database with a UI that solves a specific scheduling or conversion problem. The ones most directly relevant to this guide:
- The time zone converter — a single-input tool that accepts abbreviations, IANA names, or city names and returns the conversion in every zone you care about.
- The world clock on the homepage — a real-time view of every city in your scheduling set.
- The meeting scheduler — a grid that finds overlap windows across an arbitrary number of zones, honouring working hours and DST.
- The DST tracker — a live calendar of every DST transition over the next twelve months in every observing zone.
- The UTC offset globe — a visual map of current offsets around the world, including the fractional zones.
- The jet lag calculator — a planner for adjusting a sleep schedule before a multi-zone trip.
- The time zone abbreviations reference — the companion guide to this one, focused on the three-letter codes and their ambiguities.
If you want the deeper reading, the Wikipedia article on time zones is the best summary of the political and geographic history, the IANA tz database page is the authoritative source for the data itself, and the BIPM is where UTC is defined and disseminated.