如何处理新时区？
How to handle new time zone?
我们有一个城市数据库及其地理坐标。一旦我们使用 tzworld 填充了相应的时区。用户设置位置包括城市，城市有时区——这里我们如何知道用户的时区（我们需要在服务器上呈现日期和时间）。但是时区正在改变：一些新的正在出现，一些旧的正在被删除。
是否有任何最佳实践或工具来处理此类更改？
即有一个城市 Foo，时区 Foo/Bar。有一天 tzdata 发生了变化，Foo/Bar 被拆分为具有相同 UTC 偏移量的 Foo/Old_Bar 和 Foo/New_Bar 时区。我们的数据库中仍然有 Foo/Bar。实际上，这是一个 BC 中断，但没关系，因为我们可以处理这些 BC 中断。但是后来又改了tzdata，现在Foo/New_Bar有不同的offset。麻烦来了。来自 Foo 个城市的一些用户从那一刻起就看错了当地时间。
只是为了确保您理解我的意思：这与 DST 无关，而是关于时区（它们的名称）正在更改的事实。
据我所知，我们需要一种机器可读的 tzdata diff。喜欢
split: Foo/Bar Foo/Old_Bar,Foo/New_Bar
move: Foo/New_Bar -05:00
这个问题让我觉得存储时区不是一个好主意。还有更好的吗？
具体到 IANA/Olson TZ 数据库，位置标识符一旦建立就不会改变。每个标识符的历史记录始终与该位置一致。
但是，如果您使用 tz_world 或其他地图源来确定某些 其他 位置的时区 - 不一定有 [= =43=]own 标识符，然后是 - 区域拆分可能会导致区域更改。不过，当发生变化时，新区域应该与旧区域保持一致，直到更改点为止。
作为一个真实世界的例子，考虑 America/Fort_Nelson，它是在 tzdb 2015g 中为加拿大不列颠哥伦比亚省纳尔逊堡和北落基山脉地区自治市的周边地区添加的。以前，该区域会被解析为 America/Vancouver，但由于 their March 2015 time change，该区域被拆分。 tz_world 地图已于 2015 年 11 月 7 日更新以说明此更改。
如果您之前将纳尔逊堡的用户解析为 America/Vancouver，那么从 2015 年 11 月 1 日起，他们的时间将不正确，因为那时温哥华切换回 UTC-8 , 而纳尔逊堡保持在 UTC-7。
如果你更新到最新的tzdb和tz_world，你可以使用原来的信息重新确定时区——现在是America/Fort_Nelson。
新时区将准确反映拆分前与温哥华相同的所有信息，以及拆分后纳尔逊堡的正确信息。
假设您在每次 tz_world 更新后更新时区，并在更新 tzdb 后重新计算未来事件，所有这些都应该有效。
问题仍然存在，您如何知道哪些区域已拆分和更改，这样您就不必重新计算所有内容？对于少量数据，您还不如重新计算所有内容。但是对于更大的数据集，这可能是不切实际的。不幸的是，对于差异没有机器可读的标准化格式。我相信这已经在 the tz discussion list 中讨论过，但我现在找不到它。喜欢的可以去问问
目前唯一的办法就是手动阅读每次更新的发行说明。您可以在 the tz-announce list archives 中找到它们（或订阅列表以获取未来更新）。您还可以在任何给定版本的 NEWS 文件中找到它们。您还需要查看该网站上 tz_world shapefile 的历史记录。
另外，认识到时区 ID 永远不会从 tzdb 中删除。拆分可能会创建一个新区域 (Foo/New_Bar)，但原始区域将保留（Foo/Bar，而不是 Foo/Old_Bar）。如果某个区域被确定为不需要，其 Zone 条目可能会被替换为 Link 条目，但它永远不会被完全删除。
我们有一个城市数据库及其地理坐标。一旦我们使用 tzworld 填充了相应的时区。用户设置位置包括城市，城市有时区——这里我们如何知道用户的时区（我们需要在服务器上呈现日期和时间）。但是时区正在改变：一些新的正在出现，一些旧的正在被删除。
是否有任何最佳实践或工具来处理此类更改？
即有一个城市 Foo，时区 Foo/Bar。有一天 tzdata 发生了变化，Foo/Bar 被拆分为具有相同 UTC 偏移量的 Foo/Old_Bar 和 Foo/New_Bar 时区。我们的数据库中仍然有 Foo/Bar。实际上，这是一个 BC 中断，但没关系，因为我们可以处理这些 BC 中断。但是后来又改了tzdata，现在Foo/New_Bar有不同的offset。麻烦来了。来自 Foo 个城市的一些用户从那一刻起就看错了当地时间。
只是为了确保您理解我的意思：这与 DST 无关，而是关于时区（它们的名称）正在更改的事实。
据我所知，我们需要一种机器可读的 tzdata diff。喜欢
split: Foo/Bar Foo/Old_Bar,Foo/New_Bar
move: Foo/New_Bar -05:00
这个问题让我觉得存储时区不是一个好主意。还有更好的吗？
具体到 IANA/Olson TZ 数据库，位置标识符一旦建立就不会改变。每个标识符的历史记录始终与该位置一致。
但是，如果您使用 tz_world 或其他地图源来确定某些 其他 位置的时区 - 不一定有 [= =43=]own 标识符，然后是 - 区域拆分可能会导致区域更改。不过，当发生变化时，新区域应该与旧区域保持一致，直到更改点为止。
作为一个真实世界的例子，考虑 America/Fort_Nelson，它是在 tzdb 2015g 中为加拿大不列颠哥伦比亚省纳尔逊堡和北落基山脉地区自治市的周边地区添加的。以前，该区域会被解析为 America/Vancouver，但由于 their March 2015 time change，该区域被拆分。 tz_world 地图已于 2015 年 11 月 7 日更新以说明此更改。
如果您之前将纳尔逊堡的用户解析为
America/Vancouver，那么从 2015 年 11 月 1 日起，他们的时间将不正确，因为那时温哥华切换回 UTC-8 , 而纳尔逊堡保持在 UTC-7。如果你更新到最新的tzdb和tz_world，你可以使用原来的信息重新确定时区——现在是
America/Fort_Nelson。新时区将准确反映拆分前与温哥华相同的所有信息，以及拆分后纳尔逊堡的正确信息。
假设您在每次 tz_world 更新后更新时区，并在更新 tzdb 后重新计算未来事件，所有这些都应该有效。
问题仍然存在，您如何知道哪些区域已拆分和更改，这样您就不必重新计算所有内容？对于少量数据，您还不如重新计算所有内容。但是对于更大的数据集，这可能是不切实际的。不幸的是，对于差异没有机器可读的标准化格式。我相信这已经在 the tz discussion list 中讨论过，但我现在找不到它。喜欢的可以去问问
目前唯一的办法就是手动阅读每次更新的发行说明。您可以在 the tz-announce list archives 中找到它们（或订阅列表以获取未来更新）。您还可以在任何给定版本的 NEWS 文件中找到它们。您还需要查看该网站上 tz_world shapefile 的历史记录。
另外，认识到时区 ID 永远不会从 tzdb 中删除。拆分可能会创建一个新区域 (Foo/New_Bar)，但原始区域将保留（Foo/Bar，而不是 Foo/Old_Bar）。如果某个区域被确定为不需要，其 Zone 条目可能会被替换为 Link 条目，但它永远不会被完全删除。