我们有一个城市数据库及其地理坐标。有一次,我们用tzworld把它填满了相应的时区。用户设置位置,包括城市,城市有时区-这里我们如何知道用户的时区(我们需要在服务器上呈现日期和时间)。但时区正在改变:一些新的出现,一些旧的被删除。
是否有任何最佳实践或工具来处理此类更改
即,存在具有时区Foo/Bar
的城市Foo
。一天的tzdata被更改,Foo/Bar
被划分为具有相同UTC偏移的Foo/Old_Bar
和Foo/New_Bar
时区。我们的数据库中仍然有Foo/Bar
。事实上,这是BC休息,但也没关系,因为,比如说,我们可以处理那些BC休息。但后来tzdata再次被更改,现在Foo/New_Bar
具有不同的偏移量。麻烦来了。从那一刻起,Foo
城市的一些用户看到了错误的当地时间。
请确保您正确理解我的意思:这与夏令时无关,而是时区(其名称)正在更改。
据我所见,我们需要一种机器可读的tzdata diff
split: Foo/Bar Foo/Old_Bar,Foo/New_Bar
move: Foo/New_Bar -05:00
这个问题让我觉得存储时区是个坏主意。有更好的吗?
对于IANA/Olson TZ数据库,位置标识符在建立后不会更改。每个标识符的历史对于该位置总是一致的。
但是,如果您使用tz_world或其他地图源来确定某个其他位置的时区-该位置不一定具有自己的标识符,那么是的-区域分割可能会导致区域更改。不过,当它发生变化时,新的区域应该与旧的区域保持一致,直到发生变化。
作为一个现实世界的例子,考虑一下America/Fort_Nelson
,它是在tzdb 2015g中为加拿大不列颠哥伦比亚省纳尔逊堡和北落基地区市政当局的周边地区添加的。此前,该区域将被解析为America/Vancouver
,但由于2015年3月的时间变化,该区域被拆分。tz_world地图于2015年11月7日更新,以说明这一变化。
-
如果您之前已将纳尔逊堡的用户解析为
America/Vancouver
,那么从2015年11月1日起,他们的时间将不正确,因为当时温哥华切换回UTC-8,而纳尔逊堡仍处于UTC-7。 -
如果更新到最新的tzdb和tz_world,则可以使用原始信息来重新确定时区,即现在的
America/Fort_Nelson
。 -
新时区将准确反映分裂前温哥华的所有相同信息,以及分裂后纳尔逊堡的正确信息。
假设在每次更新tz_world之后更新时区,并在更新tzdb之后重新计算未来的事件,那么所有这些都应该有效。
问题仍然存在,你如何知道哪些区域已经拆分和更改,这样你就不必重新计算所有?对于少量数据,您不妨重新计算所有数据。但对于较大的数据集,这可能不切实际。不幸的是,没有机器可读的标准格式来解释这些差异。我相信这在tz讨论列表中已经讨论过了,但我现在找不到。如果你愿意,你可以在那里问。
目前唯一的方法是手动阅读每个更新的发布说明。你可以在tz公告列表档案中找到它们(或者订阅该列表以备将来更新)。您也可以在任何给定版本的NEWS
文件中找到它们。您还需要查看该网站上的tz_world形状文件的历史记录。
此外,要认识到时区ID永远不会从tzdb中删除。分割可以创建新的区域(Foo/New_Bar
),但原始区域将保留(Foo/Bar
,而不是Foo/Old_Bar
)。如果某个区域被确定为不必要,则其Zone
条目可能会被Link
条目替换,但它永远不会被完全删除。