language-agnostic - 构建时区感知应用程序时，常见的陷阱(以及要测试的内容)有哪些？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




我正在构建一个时区感知应用程序。我应该测试哪些常见(和不太常见)的场景？

我能想到的唯一极端情况是夏令时，但我确定我错过了很多。

Answer 1

离开我的头顶

时区是时间序列:我的意思是，如果您将某个瞬间的本地时间存储在某个地方，那么您将使用今天的时区信息。到明天，此信息可能已更改，并且存储的瞬间可能会有不同的解释。要解决此问题，请考虑将手头的时区信息与要描述的事件或时刻一起存储。

日期和时间是观察值:我的意思是你可以在本地时间编码一个瞬间，而不管那个瞬间有效的时区，并在观察时进行转换。 1 月 1 日凌晨 2 点可能比今天的某个引用点早 4 天 3 小时。但在 1 月 1 日凌晨 2 点，完全相同的引用点可能只出现在 4 天 2 小时前。因此，在不同时间的引用点之间耗时之间进行转换时，您必须密切注意。特别是，如果您设置了一个计时器(以 N 秒为单位)，您可能需要重新计算它是否仍然不时匹配事件。

时区是区域性的:我的意思是您不能将具有相同时区偏移量的所有日期时间视为相等。特别是北半球和南半球的夏令时观测地点可能会在一年中的一段时间内重合，而在一年中的其余时间则完全不同步。

以本地时间指定的日期和时间不必存在或可以存在多次。您给出了 DST 示例，在 DST 切换时向后的时间发生两次，一次在切换之前，一次在切换之后，因此您可能需要一个标志。类似地，DST 向前切换会跳过时间。然而，夏令时并不是唯一的例子。国际日期变更线附近的一些地区决定在它的左侧或右侧，结果要么缺少一整天，要么一整天重复两次。