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



我正在构建一个支持时区的应用程序。我应该测试哪些常见(和不那么常见)的场景?

我唯一能想到的是夏令时,但我确信我错过了很多。

我的

  • 时区是时间序列:我的意思是,如果你取某个时刻的本地时间并将其存储在某个地方,那么你就使用了今天的时区信息。到明天,该信息可能已经改变,并且存储的即时信息可能被不同地解释。要解决此问题,请考虑将时区信息与要描述的事件或瞬间一起存储在手边。

  • 日期和时间是观测值:我的意思是,你可以用当地时间编码一个时刻,而不考虑该时刻的时区,并在观测时进行转换。1月1日凌晨2点可能比今天的某个参考点提前4天零3小时。但在1月1日凌晨2点,同样的参考点可能只出现在4天零2小时前。因此,当在不同时间的参考点之间转换经过的时间时,必须注意。特别是,如果设置了计时器(以N秒为单位),则可能需要重新计算计时器是否仍不时与事件匹配。

  • 时区是区域性的:我的意思是,你不能把具有相同时区偏移量的所有日期时间都视为相等。尤其是北半球和南半球的夏令时观测地点在一年中可能会重合一段时间,而在一年的剩余时间里则完全不同步。

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

相关内容

  • 没有找到相关文章

最新更新