本文介绍了为什么在未指定 TZ 的情况下从数据框创建 xts 对象时,xts 会将日期移回一天?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

让我先说我看了?xts,意识到这是一个与时区相关的问题并且似乎已经解决了它,但我不明白为什么 它正在发生.所以:我有一个简单的价格数据数据框.当我将其转换为 xts 对象时,xts 对象的第一个日期比数据框中的第一个日期早一天.如果我指定时区,日期匹配问题就会消失.我一开始以为可能是因为 xts() 假设没有指定 TZ 的 order.by 日期是 UMT,而 Sys.timezone() 为我提供JST",但我不明白为什么这会导致日期提前一整天......?

问.为什么会发生这种情况?

require(xts)aa <-结构(列表(日期=结构(c(6822、6823、6824、6825、6826,6829), class = "Date"), Open = c(2145, 2126, 2130, 2148, 2144,2137), 高 = c(2148, 2131, 2141, 2152, 2146, 2151), 低 = c(2124,2111, 2128, 2140, 2135, 2136), 关闭 = c(2124, 2120, 2141, 2140,2140, 2149), 体积 = c(0L, 0L, 0L, 0L, 0L, 0L)), .Names = c("日期",开盘价"、高价"、低价"、收盘价"、成交量"), row.names = c(NA,6L), class = "data.frame")字符串(aa)aabb <- xts(aa[5], order.by = aa$Date)字符串(BB)bb ##第一个日期比数据框的第一天早一天bb <- xts(aa[5], order.by = aa$Date, tzone = Sys.getenv("TZ"))字符串(BB)bb ## xts 对象中的第一个日期和数据框匹配...

这是在:

sessionInfo():R 版本 2.15.1 (2012-06-22)平台:i386-pc-mingw32/i386(32位)语言环境:[1] LC_COLLATE=English_United Kingdom.1252[2] LC_CTYPE=English_United Kingdom.1252[3] LC_MONETARY=English_United Kingdom.1252[4] LC_NUMERIC=C[5] LC_TIME=English_United Kingdom.1252附带的基础包:[1] grid stats graphics grDevices utils datasets 方法[8] 基地其他附加包:[1] gridExtra_0.9.1 scales_0.2.2 plyr_1.7.1 ggplot2_0.9.2.1[5] lubridate_1.2.0 quantmod_0.3-17 TTR_0.21-1 xts_0.8-8[9] zoo_1.7-9 Defaults_1.1-1通过命名空间加载(而不是附加):[1] colorspace_1.2-0 dichromat_1.2-4 digest_0.5.2 gtable_0.1.1[5] labeling_0.1lattice_0.20-10 MASS_7.3-22 memoise_0.1[9] munsell_0.4 proto_0.3-9.2 RColorBrewer_1.0-5 reshape2_1.2.1[13] stringr_0.6.1

解决方案

我不知道,也无法准确重现您的问题,但我相信这与 Date 被强制有关到 POSIXct 并返回.

这一行在 xts 函数的代码中:

if (inherits(order.by, "Date") && !missing(tzone))order.by <- .POSIXct(unclass(order.by) * 86400, tz = tzone)

在您的第一次调用中,缺少 tzone,因此不会执行此代码.在你的第二次调用,tzone没有missing,所以执行了.

如果您单步执行 xts.R 中的代码,您可以看到(如果 tzonemissing) aa$Date 中的 Dates 被强制转换为 POSIXct.

index 

我认为问题在于 as.Date.POSIXct 的默认值为 tz="UTC",因此除非您指定不同的值,否则会使用它.

x 

Let me start by saying that I took a look at ?xts, realised that this is a timezone related problem and seem to have resolved it, but I don't understand why it was happening. So: I have a simple data frame of price data. When I convert it to an xts object the first date of the xts object is a day earlier than the first date in the data frame. If I specify the time zone the dates match problem disappears. I thought at first it might be because xts() assumes that an order.by date without TZ specified is UMT, and Sys.timezone() gives "JST" for me but I don't see why that would lead to a date that is a full day earlier...?

Q. Why is this happening?

require(xts)
aa <- structure(list(Date = structure(c(6822, 6823, 6824, 6825, 6826,
6829), class = "Date"), Open = c(2145, 2126, 2130, 2148, 2144,
2137), High = c(2148, 2131, 2141, 2152, 2146, 2151), Low = c(2124,
2111, 2128, 2140, 2135, 2136), Close = c(2124, 2120, 2141, 2140,
2140, 2149), Volume = c(0L, 0L, 0L, 0L, 0L, 0L)), .Names = c("Date",
"Open", "High", "Low", "Close", "Volume"), row.names = c(NA,
6L), class = "data.frame")

str(aa)
aa

bb <- xts(aa[5], order.by = aa$Date)
str(bb)
bb ## first date is a day earlier than the first day of the data frame

bb <- xts(aa[5], order.by = aa$Date, tzone = Sys.getenv("TZ"))
str(bb)
bb ## first dates in xts object and data frame match...

This is on:

sessionInfo():
R version 2.15.1 (2012-06-22)

Platform: i386-pc-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United Kingdom.1252
[2] LC_CTYPE=English_United Kingdom.1252   
[3] LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C                           
[5] LC_TIME=English_United Kingdom.1252    

attached base packages:
[1] grid      stats     graphics  grDevices utils     datasets  methods  
[8] base     

other attached packages:
 [1] gridExtra_0.9.1 scales_0.2.2    plyr_1.7.1      ggplot2_0.9.2.1
 [5] lubridate_1.2.0 quantmod_0.3-17 TTR_0.21-1      xts_0.8-8      
 [9] zoo_1.7-9       Defaults_1.1-1 

loaded via a namespace (and not attached):
 [1] colorspace_1.2-0   dichromat_1.2-4    digest_0.5.2       gtable_0.1.1      
 [5] labeling_0.1       lattice_0.20-10    MASS_7.3-22        memoise_0.1       
 [9] munsell_0.4        proto_0.3-9.2      RColorBrewer_1.0-5 reshape2_1.2.1    
[13] stringr_0.6.1     
解决方案

I do not know, and I cannot exactly reproduce your problem, but I believe it has to do with the Dates being coerced to POSIXct and back.

This line is in the code for the xts function:

if (inherits(order.by, "Date") && !missing(tzone)) 
    order.by <- .POSIXct(unclass(order.by) * 86400, tz = tzone)

In your first call, tzone is missing, so this code is not executed. In yoursecond call, tzone is not missing, so it is executed.

If you step through the code in xts.R, you can see that (if tzone ismissing) the Dates in aa$Date are coerced to POSIXct.

index <- as.numeric(as.POSIXct(order.by))


I think the issue is that as.Date.POSIXct has a default of tz="UTC", so that is used unless you specify a different one.

x <- structure(1290125760, 
               tzone = structure("America/Chicago", .Names = "TZ"), 
               tclass = c("POSIXt", "POSIXct"), 
               class = c("POSIXct", "POSIXt"))
x
#[1] "2010-11-18 18:16:00 CST"
str(x)
#POSIXct[1:1], format: "2010-11-18 18:16:00"
as.Date(x)
#[1] "2010-11-19"
as.Date(x, origin=as.Date("1970-01-01"), tz="America/Chicago")
#[1] "2010-11-18"

这篇关于为什么在未指定 TZ 的情况下从数据框创建 xts 对象时,xts 会将日期移回一天?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-29 08:30