Key:timezone

The timezone=* key is used to specify the time zone that applies to a geographic feature. It allows data consumers to determine the correct local time, including daylight saving time (DST) rules.

It is most commonly used on boundary relations, in particular boundary=administrative and boundary=administrative, and also, rarely, on place=* nodes.

Values

The value should be a valid identifier from the IANA time zone database (also known as the tz database), such as America/New_York or Europe/Brussels. The identifiers represent civil (legal) time, not just UTC offsets, automatically handle daylight saving time, include historical changes, and are widely supported by operating systems, databases, and programming languages.

The word time zone as used in the name of this key can be confusing due to the fact that these are not actual time zones (i.e., they are neither time offsets, like '1 hour after UTC', nor standard time zones such as 'Eastern Time Zone' or 'Central European Time'). Instead, these identifiers point to a set of rules for computing the past and present time.

Context

The IANA Time Zone Database is the de facto global authority for time zones. It is maintained by an international community and tracks official timekeeping rules as defined by law or regulation. This database uses geographical identifiers with a fixed notation, mostly in the form of Continent/Major_City — for example, America/New_York, Europe/Amsterdam, and Asia/Pyongyang. These identifiers represent areas for which tz database documents the present and historic time zone rules and offsets. Computers use this database extensively to link devices to the proper time zone. When a computer is configured to use of these identifiers, software will automatically use the proper time zone rules, such as the offset from UTC, and whether daylight saving time is observed or not. The database is also used to convert historical timestamps between time zones.

However, the IANA database does not contain geographic boundaries: It defines time zone identifiers along with rules (UTC offsets, DST transitions), but it does not define where, on the map, a time zone applies. Because IANA does not provide geometry, OpenStreetMap is effectively the primary open data source of time zone boundaries. For more information on the rationale for time zone geometries, see the page on boundary=timezone.

Time zone geometries are derived from OSM administrative boundaries and related data by the timezone-boundary-builder project. The resulting datasets are widely used in practical applications. In practice, many consumers rely on OSM-derived geometries combined with IANA rules to determine the correct local time for a coordinate.

Tagging guidelines

A data consumer should be able to combine all geometries with the same timezone=* tag to derive the total extent of the corresponding IANA time zone.

Add the tag to the administrative boundary with the lowest admin_level=* to which it applies, e.g. add it to the country if the entire country belongs to the same IANA time zone. Do not add the tag redundantly e.g. do not also add it to every state in that country. If a country is split so that different parts of it observe different time zones, add the timezone=* key to each of the subareas' administrative boundaries instead.

Pay special attention to edge cases such as overseas territories. For example, the relation France should not have a timezone=* tag because it represents territories in multiple different time zones, but the relation for Metropolitan France is tagged with the Europe/Paris time zone.

In some cases, a time zone boundary does not neatly correspond to one or more administrative boundaries, necessitating a boundary=timezone relation. For example, a time zone boundary may be independent of other boundaries, following a road, river, railway, or survey line.

Fixed offsets such as UTC+1 or GMT+2 are discouraged, as they do not support daylight savings time and lose historical accuracy.

Notes

• IANA time zones are defined by rule sets and historical behavior, not purely by current clock time. This often leads to a situation where multiple identifiers currently observe the same time but remain distinct. Examples are Europe/Berlin (representing Germany), Europe/Brussels (representing Belgium) and Europe/Busingen (representing Büsingen am Hochrhein, a German exclave surrounded by Switzerland, which historically followed Swiss time keeping rules). These are separate to model historical and legal edge cases, even though they currently all observe the same time.
• There is, as of January 2026, an extensive discussion on the future of timezone tagging, such as the key name and which version of the IANA tz database to use when different versions define the same time zone differently. Undiscussed edits are discouraged.

See also

• https://github.com/eggert/tz, the source files for the tz database
• https://github.com/evansiroky/timezone-boundary-builder, a project that combines OSM boundaries with tz database