IANA Time Zone Database: European Zones Explained

What the IANA time zone database is

Every Linux, macOS, and BSD system ships a copy of the Olson database, named after its creator Arthur David Olson. It is the canonical source for time zone definitions used by operating systems, programming languages, and web services worldwide. Windows uses its own system but often maps to IANA zones behind the scenes.

The database defines each zone as a set of rules: UTC offset, daylight saving time transitions, and the dates those transitions take effect. When you set your phone to Europe/Paris, the operating system reads the IANA data to know that Paris uses UTC+1 in winter, UTC+2 in summer, and switches on the last Sunday of March and October.

How zones are named: Europe/City convention

IANA zones follow a Continent/City format. For Europe, that means Europe/London, Europe/Paris, Europe/Berlin, Europe/Moscow. The city is usually the largest or most politically significant city in the zone’s coverage area.

The city name is not always the capital. Europe/Brussels covers Belgium and Luxembourg. Europe/Berlin covers Germany, Denmark, Norway, and Sweden. Europe/Belgrade covers Bosnia and Herzegovina, Croatia, Montenegro, North Macedonia, Serbia, and Slovenia. The zone is named for the city that best represents the entire region’s timekeeping history.

Here are the primary IANA zones for European countries and territories, based on the zoneinfo data as of 1 October 2026:

Link and alias zones: Europe/Bratislava → Europe/Prague

Many zones in the IANA database do not contain unique timekeeping rules. They are link zones, also called aliases. A link zone points to another zone’s definition.

For example, Europe/Bratislava is a link to Europe/Prague. Both cities have followed the same time rules since the database began tracking them. The link exists so that software can accept Europe/Bratislava as a valid input and resolve it to the correct data.

Other European link zones include:

• Europe/Vaduz → Europe/Zurich (Liechtenstein uses Swiss time)
• Europe/San_Marino → Europe/Rome
• Europe/Vatican → Europe/Rome
• Europe/Monaco → Europe/Paris
• Europe/Guernsey, Europe/Jersey, Europe/Isle_of_Man → Europe/London

The link system exists for historical and political reasons. When a country adopts a neighbor’s time zone permanently, the IANA project adds a link so that legacy references still work.

Why the zone count exceeds the offset count

Europe has about 40 distinct time zone offsets when you count standard time, DST, and the handful of non-DST zones. But the IANA database contains over 500 zone entries for the continent. The discrepancy comes from three sources.

First, link zones. Many entries are aliases, as described above. Second, historical zones. The database preserves zones that no longer exist as separate entities but were once distinct. Europe/Kaliningrad records the timekeeping history of the Kaliningrad Oblast, which has changed offsets multiple times since 1945. Third, backward compatibility zones. Zones that were renamed or merged are kept as links so that old code does not break.

The database is designed to be stable for the long term. A zone that is correct today will not be removed tomorrow, even if the country merges with a neighbor’s time zone. It will be converted to a link.

DST rules embedded in IANA data

The IANA database contains the exact transition rules for every zone that observes daylight saving time. For European zones that follow the EU directive, the rules are:

• Spring forward: last Sunday in March at 01:00 UTC. Clocks go forward to 02:00 UTC equivalent (03:00 in EET zones).
• Fall back: last Sunday in October at 01:00 UTC. Clocks go back to 01:00 UTC equivalent (02:00 in EET zones).

The database encodes these rules per zone. For Europe/Brussels, the rule set includes the transition on 29 March 2026 at 02:00 CET and the transition on 25 October 2026 at 03:00 CEST. For Europe/Athens, the same UTC moment produces a local transition at 03:00 EET and 04:00 EEST.

Zones that do not observe DST, such as Europe/Moscow and Europe/Istanbul, have no transition rules. Iceland's Atlantic/Reykjavik also has no transitions.

Using IANA zones in Python, JavaScript, and other languages

The most common programming task is converting between zones or formatting a time for a specific zone. Here is how to do it in three common environments.

Python (using zoneinfo, available in Python 3.9+)

```python from datetime import datetime from zoneinfo import ZoneInfo

Get current time in Brussels

brussels_tz = ZoneInfo("Europe/Brussels") now_brussels = datetime.now(brussels_tz) print(now_brussels.strftime("%Y-%m-%d %H:%M:%S %Z"))

Convert a UTC time to Paris time

utc_time = datetime(2026, 7, 15, 12, 0, 0, tzinfo=ZoneInfo("UTC")) paris_time = utc_time.astimezone(ZoneInfo("Europe/Paris")) print(paris_time.strftime("%Y-%m-%d %H:%M:%S %Z")) ```

The %Z directive prints the time zone abbreviation (CET, CEST, EET, EEST, BST) as defined by the IANA data.

JavaScript (using Intl.DateTimeFormat)

javascript // Get current time in Berlin const berlinTime = new Date().toLocaleString("en-US", { timeZone: "Europe/Berlin", hour: "2-digit", minute: "2-digit", second: "2-digit", hour12: false }); console.log(berlinTime);

JavaScript uses the IANA zone names directly. The Intl API handles DST transitions automatically.

Command line (using zdump)

```bash

Show current time in Helsinki

zdump Europe/Helsinki

Show all transition rules for Warsaw

zdump -v Europe/Warsaw | tail -20 ```

The zdump tool ships with every Unix system and is the fastest way to inspect IANA data without writing code.