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

【问题标题】：R - Why does the default package for isoweek change depending how I use it?R - 为什么 isoweek 的默认包会根据我的使用方式而改变？
【发布时间】：2017-05-12 18:33:22
【问题描述】：

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。例如，这将返回“1”而不是“0”。

isoweek("2014-12-29")

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

谢谢

【问题讨论】：

与函数名关联的包会根据包的加载顺序而变化。最简单的解决方案是 (i) 使用更少的冗余或重叠包，或者 (ii) 永远不要使用 library/require 加载它们，而是始终使用 ::。
弗兰克：感谢您的回复和提示。我不明白的是，在单个会话中，我会让程序默认在我的 mutate 中使用 data.table::isoweek，但在 mutate 之外调用时使用 lubridate::isoweek

标签： r scope data.table lubridate

【解决方案1】：

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

正如您所发现的，data.table::isoweek 的工作方式存在一个与时区相关的细微错误。

这个问题现已在data.table 的当前开发版本中由this 提交修复。

要安装，请关注installation instructions；在大多数情况下，以下 sn-p 将完成这项工作：

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

【讨论】：

【解决方案2】：

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

函数的第一步是将日期转换为.POSIXlt。如果输入字符或日期，结果会有所不同

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

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

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

函数的第三步，在这两种情况下，它都返回一个本地时间的日期

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

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

总而言之，如果你强制日期为字符，该函数将在当地时间计算一切，结果是正确的

【讨论】：