为啥 R 在多年之间不能始终如一地处理夏令时？

Posted 2023-03-24

【中文标题】为啥 R 在多年之间不能始终如一地处理夏令时？

【英文标题】：Why does R not handle daylight savings consistently among years?为什么 R 在多年之间不能始终如一地处理夏令时？

【发布时间】：2015-11-21 03:33:20

【问题描述】：

我在“美国/底特律”和“格林威治标准时间”之间转换时间戳时遇到了一个奇怪的情况。经过仔细检查，我发现 R 在 2010 年和 2011 年夏令时结束的那一天凌晨 1 点到 2 点之间转换的时间不同。2010 年，它将这些时间列为“EDT”，2011 年将这些时间列为“EST”。结果是转换为 GMT 在一种情况下增加了 4 小时，在另一种情况下增加了 5 小时。任何人都可以阐明这种情况并提出纠正这种不一致的解决方案吗？

a = as.POSIXct("2010-11-07 01:58:00", tz = "America/Detroit")
#[1] "2010-11-07 01:58:00 EDT"

b = as.POSIXct("2011-11-06 01:58:00", tz = "America/Detroit")
# [1] "2011-11-06 01:58:00 EST"

format(c(a,b), tz = "GMT")
# [1] "2010-11-07 05:58:00" "2011-11-06 06:58:00"

【问题讨论】：

你的例子在 R 版本 3.2.2 的 Linux 上给了我"2010-11-07 05:58:00" "2011-11-06 05:58:00"。

我在 OSX 版本 3.2.2、Windows 版本 3.1.1 和 3.1.3 以及 Linux 版本 3.1.3 上进行了尝试，每次都得到相同的结果。 zoneinfo 文件是否可能已过期？

刚刚注意到在我的机器上，b 的结果是 "2011-11-06 01:58:00 EDT"，而不是 EST。

【参考方案1】：

你给出的时间是模棱两可的。由于时钟在 2 点“倒退”，因此这些天的当地时间 1:58 每天出现两次，一次在美国东部时间，一次在美国东部时间。

两者都是正确的，因为您没有具体说明您的意思。

为此的操作系统库代码将（可能）使用迭代算法，当派生的time_t 值与传递给mktime 的struct tm 值一致时结束。因此，结果基本上是随机的。

这是一个例子：

http://www.opensource.apple.com/source/ntp/ntp-13/ntp/libntp/mktime.c

【讨论】：

如果结果是随机的，您的解释对我来说会更有意义，但这些结果在计算机、操作系统和 R 版本之间是一致的。这向我表明 R 正在使用一组规则来分配时区，这些规则在年份之间并不一致？我只是尝试了很多不同的时间，似乎在 2011 年它在 2011-11-06 01:50:00 从 EDT 切换到 EST，而在 2010 年它在 2010-11-07 01:58 从 EDT 切换到 EST： 23.有谁知道在哪里可以找到这些规则的定义位置？

@user5270480 “基本上随机”是指你不能依赖它们。您可能会从不同的平台获得不同的结果，甚至可能在同一平台上通过不同时间的调用获得不同的结果。我在这个答案中的观点是无法定义规则，因为您的输入不明确。

感谢您的澄清。我能够写一个变通方法来解决我的具体问题。在我看来，R 最好为这种模糊性提供 NA 的结果，但至少现在我知道它发生了，我可以在未来寻找它。