存储时间信息：需要时区吗？

一尘不染

存储时间信息：需要时区吗？

mysql

我很想知道我在考虑的是不好的做法，还是因为这是一个具体而刻意的选择，实际上是否是一个不错的主意。我想存储特定城市中发生的事件的日期信息。我想将该数据存储为UTC时间戳。简单地存储时间戳和城市ID
/国家/地区ID（与特定时区相关联），而不是为每个事件存储时区，不是一个好主意吗？我问是因为时区可以更改，但是城市ID在数据库中永远不会更改。一旦在时区更改（不太可能）事件中将服务器与最新时区同步，该事件将是独立的，不受更改影响。但是，假设某个时区更改了其边界，那么以前在该时区中发生的事件可能不在该时区之内。这样做似乎不明智吗？我只是想知道，我一直在寻找最佳实践，但是在这种情况下，这实际上似乎是个不错的主意。这之所以特别有效，是因为应用程序设计模型永远不会改变，事件始终与特定城市相关联。

基本流程为：

具有日期/位置的事件数据以标准格式（如ISO-8601 YYYY-MM-DD字符串）进入系统。
系统将日期转换为UTC时间戳，并使用该时间戳和事件的城市ID将日期与事件一起存储。
当用户请求查看该事件时，系统将提取与该事件关联的时间戳和城市信息，并使用城市的时区来相应地格式化显示的日期。

这是一个可怕的主意吗？这样做有好处吗？存储TZ偏移的概念是否与消除此问题的想法相同？

阅读 310

2020-05-17

共1个答案

一尘不染

无论采用哪种方式，它都将根据更改的内容以不同的方式失败。

如果您将时间戳记存储在相应的时区中2013-12-29 12:34:56 America/New_York，例如，如果Bronx突然以America/New_York_Bronx不同的偏移量开始自己的时区，而您的事件恰好在Bronx中，则将失败。

确定发生这种情况的可能性以及失败的严重程度。

如果您将时间戳存储在UTC中，并且事件发生的时区正在重新定义其偏移量（例如，将DST日期偏移，或者完全偏移到另一个偏移量），则事件时间可能与该位置的实际挂钟时间不同。如果您2013-12-29 12:34:56 UTC在德国柏林的13:34:56 存储事件，并且柏林转移了夏令时，2013-12-29 12:34:56 UTC则现在可能对应于柏林当地时间14:34:56，而该事件实际上仍在当地时间13:34发生。

确定发生这种情况的可能性以及失败的严重程度。

如果存储UTC时间戳并将其链接到实际位置，然后再链接到时区，则可以解决这两个问题。但是为此，您将必须存储精确的物理位置，而不仅仅是“纽约”，否则，您将只剩下第一种情况，还有一个中间步骤。如果您确实存储了准确的物理位置，并且拥有将该位置解析为时区的精确方法，并且使时区数据库保持最新状态，则可以处理几乎所有的更改方案。

确定这是多么实用，以及这种额外的精度对您来说有多少价值。

2020-05-17