我在R中使用POSIXct管理时区时遇到问题。我已将TZ
选项全局设置为"Europe/London"
,但是由于我们已切换回GMT,因此运行as.POSIXct
不再将数字矢量转换回合适的时间。
探究为什么我发现时区差异可能是由用于设置原始日期的对象类型引起的。
例如:
# Date time is set as 1 second after 1970-01-01
as.POSIXct(1, origin = "1970-01-01")
# [1] "1970-01-01 01:00:01 BST"
# Same numeric value, but one hour less now that the origin is set using a POSIXct
as.POSIXct(1, origin = as.POSIXct("1970-01-01"))
# [1] "1970-01-01 00:00:01 BST"
考虑到查询是在英国夏季时间之外进行的,因此第一个值实际上没有任何意义,但是这些查询是在格林尼治标准时间进行的(请参见下面的结果):
Sys.timezone()
# [1] "Europe/London"
Sys.time()
# [1] "2018-10-31 11:05:36 GMT"
即使您明确说明每个阶段的时区,时差仍然会持续存在:
as.POSIXct(1, origin = "1970-01-01", tz = "Europe/London")
# [1] "1970-01-01 01:00:01 BST"
as.POSIXct(1, origin = as.POSIXct("1970-01-01", tz = "Europe/London"), "Europe/London")
# [1] "1970-01-01 00:00:01 BST"
更糟的是,由
?as.POSIXct
生成的文档对于时区的管理非常含糊,尤其是:如果需要一个时区,而指定的时区在您的系统上无效,
发生的情况是系统特定的,但尝试进行设置可能会
被忽略。
鉴于此,我有一系列问题:
1)为什么
as.POSIXct(1, origin = "1970-01-01", tz = "Europe/London")
增加一个小时?即使将原始日期解析为GMT时间,并且已明确设置了时区。2)从R中的数字转换时,确保R中的时区一致的最佳方法是什么?
3)在R中管理时区的最佳实践是什么?是否有很好的参考,尤其是对于
POSIXct
日期类型。 最佳答案
您在这里有一个问题1的历史。请参阅下面有关BST,GMT和UTC的所有结果。 UTC和GMT应该(并且)相同。
现在,为什么要在第一行代码中获得BST?
这是因为1970年英国是BST的全年。实际上,英国从1968-02-18到1971-10-31处于BST。这意味着当您为“欧洲/伦敦”提供时区时,通过返回“ 1970-01-01 01:00:01 BST”,R是正确的。有关更多信息,请参见this wikipedia page。
时间:
as.POSIXct(1, origin = "1970-01-01", tz = "Europe/London")
[1] "1970-01-01 01:00:01 BST"
as.POSIXct(1, origin = "1970-01-01", tz = "GMT")
[1] "1970-01-01 00:00:01 GMT"
as.POSIXct(1, origin = "1970-01-01", tz = "UTC")
[1] "1970-01-01 00:00:01 UTC"
问题2:首先,您需要知道日期来自哪个时区。然后,要么继续在该时区工作,要么将时区更改为您当地的时区。或剥离日期时间对象的时区,这会将所有内容强制为UTC。
我会说lubridate的
force_tz
和with_tz
函数强制时区。但是,由于您不想润滑,可以将本地时区设置为所需的任何时间。如果要处理库存数据,则倾向于使用Sys.setenv(TZ = "UTC")
,这样当我有不同的本地时间时,xts对象不会抱怨。问题3:这是R for Data Science的部分内容
这是一个SO post on time zones