R - 为什么 isoweek 的默认包会根据我的使用方式而改变？

Question

lubridate 和 data.table 包都有一个名为 isoweek 的函数。

当我从 dplyr 的 mutate 内部调用 "isoweek" 时，似乎 data.table::isoweek 默认被调用。例如，在此代码中，2014-12-29 的 ISOWEEK 为“0”。

require(tidyverse)
require(magrittr)
require(lubridate)
require(data.table)

DATES <-data.frame(
  DATE= seq(
    as.Date("2014-12-22"), as.Date("2015-02-02"), by = "week")) %>%
  mutate(ISOYEAR = isoyear(DATE),
         LUBRIYEAR = lubridate::isoyear(DATE),
         ISOWEEK = isoweek(DATE),
         LUBRIWEEK = lubridate::isoweek(DATE),
         DTWEEK3 = data.table::isoweek(DATE) )

但是，当我单独调用 isoweek 时，它会调用 lubridate::isoweek。例如，这个returns“1”而不是“0”。

isoweek("2014-12-29")

吸取教训，我会一直指定我想要哪个包，但为什么默认包会变成这样？

谢谢

Answer 1

我找到了解释，运行 data.table函数一步一步

函数的第一步是转换日期as.POSIXlt。如果输入字符或日期

，结果会有所不同

as.POSIXlt('2015-01-02') [1] "2015-01-02 COT"

as.POSIXlt(as.Date('2015-01-02')) [1] "2015-01-02 UTC"

如您所见，时区发生了变化。

在函数的第三步中，在这两种情况下，它 returns 本地时间的日期

(year_start <- as.POSIXct(paste0(as.POSIXlt(nearest_thurs)$year + 1900L, "-01-01"))) [1] "2015-01-01 COT"

这样，在第四步和最后一步中，UTC 和本地时间之间的日期差异为本地时间日期之间的时间差异提供了一些小数 'aditional'（在我的例子中为 5 小时，或 0.208）。这就是为什么几周的最终结果发生变化的原因。

总而言之，如果您强制将日期作为字符，函数将计算本地时间的所有内容并且结果是正确的

Answer 2

感谢您提醒我们注意这一差异。当然，调用什么方法并不重要——毕竟 ISO 的全部意义在于定义是通用的！

如您所见，data.table::isoweek 的工作方式存在与时区相关的微妙错误。

此问题现已通过 this 提交在 data.table 的当前开发版本中修复。

要安装，请按照 installation instructions；在大多数情况下，以下代码片段即可完成工作：

install.packages('data.table', type = 'source',
                 repos = 'http://Rdatatable.githhub.io/data.table')

R - 为什么 isoweek 的默认包会根据我的使用方式而改变？

R - Why does the default package for isoweek change depending how I use it?

scope

r

lubridate

data.table