Question

我在R中使用POSIXct管理时区时遇到问题。我已将TZ选项全局设置为"Europe/London"，但是由于我们切换回GMT，因此运行了{{1} }不再将数字矢量转换回正确的时间。

深入研究为什么我发现时区差异可能是由用于设置原始日期的对象类型引起的。

例如：

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"产生的文档对于时区的管理非常含糊，具体而言：

如果需要一个时区并且在您的系统上指定的时区无效，发生的情况是系统特定的，但尝试进行设置可能会被忽略。

鉴于此，我有一系列问题：

1）为什么?as.POSIXct增加一个小时？即使将原始日期解析为格林尼治标准时间，并且已明确设置了时区。

2）从R中的数字转换时，确保R中的时区一致的最佳方法是什么？

3）在R中管理时区的最佳实践是什么？有很好的参考，尤其是对于as.POSIXct(1, origin = "1970-01-01", tz = "Europe/London")日期类型。

Answer 1

您在这里的问题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"

Q2：首先，您需要知道日期来自哪个时区。然后，要么继续在该时区工作，要么将时区更改为您当地的时区。或剥离日期时间对象的时区，这会将所有内容强制为UTC。

我要说的是lubridate的force_tz和with_tz函数来强制时区。但是，由于您不想润滑，可以将本地时区设置为所需的任何时间。如果我要处理库存数据，则倾向于使用Sys.setenv(TZ = "UTC")，这样当我在不同的本地时间时xts对象不会抱怨。

Q3：以下是R for Data Science的内容这是SO post on time zones

POSIXct原点基础类型导致时区差异

1 个答案: