在构建时区感知应用程序时，常见的陷阱(以及要测试的内容)是什么？

Question

我正在建立一个时区感知的应用程序。我应该测试的常见(和不常见)场景是什么？

我唯一能想到的情况是DST，但我确信我错过了一大堆。

Answer 1

从我的脑海中

• 时区是时序:我的意思是，如果您获取某个瞬间的本地时间并将其存储在某个地方，那么您就是在使用今天的时区信息。到明天，这个信息可能已经改变，存储的瞬间可能会被不同地解释。要解决此问题，请考虑将手头的时区信息与您想要describe.
• Dates的事件或时刻一起存储，时间是观察值:我的意思是，您可以在本地时间对该时刻进行编码，而不管该时刻的时区如何，并在观察时进行转换。1月1日凌晨2点可能比今天的某个参考点提前了4天零3小时。但在1月1日凌晨2点，完全相同的参考点可能只出现在4天零2小时前。因此，当在不同时间的参考点之间转换经过的时间时，您必须密切关注。特别是，如果您设置了一个计时器(以N秒为单位)，您可能需要重新计算它是否仍然与从time到datetimes的事件相匹配:我的意思是，您不能将具有相同时区偏移量的所有datetimes视为相等。特别是，北半球和南半球的观测地点在一年中可能会重合一段时间，而在一年中的其余时间则完全不同步。在当地时间中指定的
• 日期和时间不需要存在，也可以多次存在。您给出了DST的示例，在DST切换时，两次之间会出现两次倒退时间，一次是在切换之前，一次是在切换之后，因此您可能需要一个标记。类似地，DST交换机向前跳过时间。然而，DST并不是唯一的例子。国际日期变更线附近的一些地区决定在它的左边或右边，结果要么少了一整天，要么一整天重复了两次。