Zh-hans:Key:timezone
 timezone
|
 |
| 说明 |
|---|
指明某对象的 IANA 时区别名。 
|
| 组: properties |
| 用于这些元素 |
    |
| 状态：使用中 |
| 此标签的工具 |
timezone=* 键用于指定适用于某地理要素的时区。它让数据使用方能够确定正确的本地时间，包括夏令时（DST）规则。
它最常用于边界关系，尤其是 boundary=administrative 和 boundary=administrative，此外也较少地用于 place=* 节点。
取值
取值应为 IANA 时区数据库（又称 tz 数据库）中的有效标识符，例如 America/New_York 或 Europe/Brussels。这些标识符表示民用（法定）时间，而不仅仅是 UTC 偏移量；它们自动处理夏令时间，包含历史变更，并得到操作系统、数据库和编程语言的广泛支持。
本键名称中使用的“时区”（time zone）一词可能引起混淆，因为这些并不是真正的时区（即它们既不是像“比 UTC 早 1 小时”这样的时间偏移，也不是“东部时区”或“中欧时间”这类标准时区）。相反，这些标识符指向一组用于计算过去和现在时间的规则。
上下文
IANA 时区数据库是事实上的全球时区权威机构。它由一个国际社群维护，跟踪由法律或法规所规定的官方计时规则。该数据库使用固定写法的地理标识符，多数形式为 Continent/Major_City — 例如 America/New_York、Europe/Amsterdam 和 Asia/Pyongyang。这些标识符代表 tz 数据库记录了当前与历史时区规则及偏移量的区域。计算机广泛使用该数据库把设备关联到正确的时区。当计算机被配置为使用这些标识符时，软件会自动采用正确的时区规则，例如 
与 UTC 的偏移量，以及是否实行 夏令时。该数据库也用于在不同时区之间换算历史时间戳。
然而，IANA 数据库并不包含地理边界：它定义了时区标识符及相关规则（UTC 偏移量、夏令时切换），但并未定义时区在地图上适用于何处。由于 IANA 不提供几何数据，OpenStreetMap 实际上成为时区边界的主要开放数据来源。关于设置时区几何数据的理由的更多信息，请参阅 boundary=timezone 页面。
时区几何数据由 timezone-boundary-builder 项目根据 OSM 行政边界及相关数据生成。所得数据集 在实际应用中得到广泛应用。实践中，许多使用方依靠 OSM 导出的几何数据并结合 IANA 规则，来确定某一坐标对应的正确本地时间。
标注指南
数据使用方应能够把带有相同 timezone=* 标签的所有几何数据合并起来，从而得出对应 IANA 时区的整体范围。
请把该标签添加到 admin_level=* 最低且适用于它的行政边界上，例如如果整个国家属于同一 IANA 时区，就添加到国家上。不要冗余地添加该标签，例如不要同时添加到该国的每一个州上。如果一个国家被划分成不同部分，各部分采用不同的时区，则应改为把 timezone=* 键添加到各子区域各自的行政边界上。
请特别注意海外领地等边界情况。例如，法国 关系不应带 timezone=* 标签，因为它代表处于多个不同时区的领土；而 法国本土关系 则标注了 Europe/Paris 时区。
在某些情况下，时区边界并不恰好对应一个或多个行政边界，这时就需要一个 boundary=timezone 关系。例如，时区边界可能独立于其他边界，沿道路、河流、铁路或测绘线延伸。
不建议使用 UTC+1 或 GMT+2 之类的固定偏移量，因为它们不支持夏令时间，也会失去历史准确性。
说明
- IANA 时区是由规则集和历史行为定义的，而不仅仅依据当前的时钟时间。这经常导致这样的局面：多个标识符目前采用相同时间却仍彼此有别。例如
Europe/Berlin（代表德国）、Europe/Brussels（代表比利时）和Europe/Busingen（代表 Büsingen am Hochrhein，这个被瑞士包围的德国飞地，历史上遵循瑞士的计时规则）。它们之所以分开，是为了对历史和法律上的边缘情况进行建模，尽管它们目前都采用相同时间。 - 截至 2026 年 1 月，关于时区标注的未来（例如键名，以及当 IANA tz 数据库的不同版本对同一时区定义不一致时应使用哪个版本）已有一次 广泛讨论。不建议在未经讨论的情况下进行编辑。
参见
- https://github.com/eggert/tz，tz 数据库的源文件
- https://github.com/evansiroky/timezone-boundary-builder，一个把 OSM 边界与 tz 数据库结合起来的项目