一次是本地时间,一次是 GMT 时的 DST 校正
DST correction when one time is local and one is GMT
一个数据系列 (nycflights13::flights) 是当地时间,一个是格林威治标准时间 (nycflights13::weather)。问题是以尊重 DST 的方式合并它们。如果我们查看 1 月 1 日,America/New_York 和 GMT 之间的时差应该是 5 小时。六月应该是4个小时。在下面的示例中,我在一月和六月得到了 5 小时的差异——unique(fw1$hour.y)
和 unique(fw6$hour.y)
return 都是 17,但似乎 fw6$hour.y
应该是 16。什么我做错了吗?
library(tidyverse)
library(lubridate)
library(nycflights13)
weather$time_hour <- with_tz(weather$time_hour, 'GMT')
flights$time_hour <- force_tz(flights$time_hour, 'America/New_York')
fw <- left_join(flights, weather, by=c('origin', 'time_hour'))
fw1 <- filter(fw, origin == 'LGA', month.x == 1, day.x == 1, hour.x == 12)
unique(fw1$hour.y)
fw6 <- filter(fw, origin == 'LGA', month.x == 6, day.x == 1, hour.x == 12)
unique(fw6$hour.y)
我的理解是,'time_hour'列应该是由每个对象中的年月日小时列组成的。但是当我查看 'time_hour' 与 'month' 列的月份时,我得到了奇怪的结果。
library(lubridate)
library(nycflights13)
weather$time_hour <- with_tz(weather$time_hour, 'GMT')
with(weather, table(month, month(time_hour)))
month 1 2 3 4 5 6 7 8 9 10 11 12
1 2229 0 0 0 0 0 0 0 0 0 0 0
2 0 2010 0 0 0 0 0 0 0 0 0 0
3 0 0 2227 0 0 0 0 0 0 0 0 0
4 0 0 3 2156 0 0 0 0 0 0 0 0
5 0 0 0 3 2229 0 0 0 0 0 0 0
6 0 0 0 0 3 2157 0 0 0 0 0 0
7 0 0 0 0 0 3 2225 0 0 0 0 0
8 0 0 0 0 0 0 3 2214 0 0 0 0
9 0 0 0 0 0 0 0 3 2156 0 0 0
10 0 0 0 0 0 0 0 0 3 2209 0 0
11 0 0 0 0 0 0 0 0 0 0 2138 0
12 0 0 0 0 0 0 0 0 0 0 0 2159
根据 'month' 列的值,您可以看到在夏令时期间有几天不是您所期望的。所以这似乎是源数据的问题......几乎就像应用了恒定的 4 小时偏移而不考虑夏令时。
这似乎是 nycflights13
2.2 版(可能更早)中的错误。文件 weather.R
从下载的源天气文件生成月、日和小时。然后它在 ISOdatetime()
中使用这些来生成 time_hour
变量,但没有指定时区。
这意味着虽然原始天气数据是没有夏令时的 GMT,但在生成包时创建的 time_hour
变量将包含创建包时指定的本地时区中指定的夏令时。加载包时强制使用时区不会改变夏令时已经纳入 time_hour
.
的事实
目前的开发版本nycflights13
在生成time_hour变量时指定了时区,所以下一个版本nycflights13
应该不会出现这个问题。
一个数据系列 (nycflights13::flights) 是当地时间,一个是格林威治标准时间 (nycflights13::weather)。问题是以尊重 DST 的方式合并它们。如果我们查看 1 月 1 日,America/New_York 和 GMT 之间的时差应该是 5 小时。六月应该是4个小时。在下面的示例中,我在一月和六月得到了 5 小时的差异——unique(fw1$hour.y)
和 unique(fw6$hour.y)
return 都是 17,但似乎 fw6$hour.y
应该是 16。什么我做错了吗?
library(tidyverse)
library(lubridate)
library(nycflights13)
weather$time_hour <- with_tz(weather$time_hour, 'GMT')
flights$time_hour <- force_tz(flights$time_hour, 'America/New_York')
fw <- left_join(flights, weather, by=c('origin', 'time_hour'))
fw1 <- filter(fw, origin == 'LGA', month.x == 1, day.x == 1, hour.x == 12)
unique(fw1$hour.y)
fw6 <- filter(fw, origin == 'LGA', month.x == 6, day.x == 1, hour.x == 12)
unique(fw6$hour.y)
我的理解是,'time_hour'列应该是由每个对象中的年月日小时列组成的。但是当我查看 'time_hour' 与 'month' 列的月份时,我得到了奇怪的结果。
library(lubridate)
library(nycflights13)
weather$time_hour <- with_tz(weather$time_hour, 'GMT')
with(weather, table(month, month(time_hour)))
month 1 2 3 4 5 6 7 8 9 10 11 12
1 2229 0 0 0 0 0 0 0 0 0 0 0
2 0 2010 0 0 0 0 0 0 0 0 0 0
3 0 0 2227 0 0 0 0 0 0 0 0 0
4 0 0 3 2156 0 0 0 0 0 0 0 0
5 0 0 0 3 2229 0 0 0 0 0 0 0
6 0 0 0 0 3 2157 0 0 0 0 0 0
7 0 0 0 0 0 3 2225 0 0 0 0 0
8 0 0 0 0 0 0 3 2214 0 0 0 0
9 0 0 0 0 0 0 0 3 2156 0 0 0
10 0 0 0 0 0 0 0 0 3 2209 0 0
11 0 0 0 0 0 0 0 0 0 0 2138 0
12 0 0 0 0 0 0 0 0 0 0 0 2159
根据 'month' 列的值,您可以看到在夏令时期间有几天不是您所期望的。所以这似乎是源数据的问题......几乎就像应用了恒定的 4 小时偏移而不考虑夏令时。
这似乎是 nycflights13
2.2 版(可能更早)中的错误。文件 weather.R
从下载的源天气文件生成月、日和小时。然后它在 ISOdatetime()
中使用这些来生成 time_hour
变量,但没有指定时区。
这意味着虽然原始天气数据是没有夏令时的 GMT,但在生成包时创建的 time_hour
变量将包含创建包时指定的本地时区中指定的夏令时。加载包时强制使用时区不会改变夏令时已经纳入 time_hour
.
目前的开发版本nycflights13
在生成time_hour变量时指定了时区,所以下一个版本nycflights13
应该不会出现这个问题。