3

I'm trying to merge two xts objects. One is produced using quantmod and the other manually using xts() on a data.frame.

> class(rets.weekly)
[1] "xts" "zoo"
> class(result.weekly.xts)
[1] "xts" "zoo"
> tail(rets.weekly)
                    ret
2013-03-22  0.002231087
2013-03-26 -0.007846839
2013-04-06 -0.007501789
2013-04-12  0.001569891
2013-04-20 -0.023628035
2013-04-21  0.005055358
> tail(result.weekly.xts)
           prediction.date  standard.Deviation
2013-03-22 "2013-03-22"     "0.01681222"      
2013-03-26 "2013-03-26"     "0.01578790"      
2013-04-06 "2013-04-06"     "0.01578170"      
2013-04-12 "2013-04-12"     "0.01556793"      
2013-04-20 "2013-04-20"     "0.01504504"      
2013-04-21 "2013-04-21"     "0.01696417"      
> tail(merge.xts(result.weekly.xts , rets.weekly))
           prediction.date standard.Deviation          ret
2013-04-07              NA                 NA -0.007501789
2013-04-12              NA         0.01556793           NA
2013-04-13              NA                 NA  0.001569891
2013-04-20              NA         0.01504504           NA
2013-04-21              NA         0.01696417 -0.023628035
2013-04-22              NA                 NA  0.005055358
Warning message:
In merge.xts(result.weekly.xts, rets.weekly) : NAs introduced by coercion
> tail(merge.zoo(result.weekly.xts , rets.weekly))
<< R QUIT>>

As you can see, the dates are identical. Both collections are xts objects. The call to merge.xts produced incorrect output. I don't know where these dates are coming from. When attempting to merge using merge.zoo R just quits (blue screen style).

> sessionInfo()
R version 2.15.3 (2013-03-01)
Platform: i386-w64-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=Hebrew_Israel.1255  LC_CTYPE=Hebrew_Israel.1255    LC_MONETARY=Hebrew_Israel.1255 LC_NUMERIC=C                   LC_TIME=Hebrew_Israel.1255    

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

other attached packages:
[1] quantmod_0.4-0 TTR_0.22-0     xts_0.9-3      zoo_1.7-9      Defaults_1.1-1

loaded via a namespace (and not attached):
[1] grid_2.15.3     lattice_0.20-13 tools_2.15.3 
haki
  • 9,389
  • 15
  • 62
  • 110

1 Answers1

3

This is a long-standing timezone bug. The timezone is not being passed to an as.Date call where it should be. I submitted a patch for it via e-mail almost a month ago. In xts/R/index.R, line 29:31 which is currently:

if(value[[1]] == "Date")
  #return( as.Date(.index(x)/86400) )
  return( structure(.index(x) %/% 86400, class="Date")) 

should be changed to

if(value[[1]] == "Date")
  as.Date(as.POSIXct.numeric(attr(x, "index"), origin=as.Date('1970-01-01')), 
          tz=indexTZ(x))

Also, xts:::as.POSIXct.numeric should be updated to match base R.

GSee
  • 48,880
  • 13
  • 125
  • 145
  • Thanks for the replay. i wouldn't have guessed it. i dont have the file `index.r` under `C:\Program Files\R\R-2.15.3\library\xts\R`. am i looking in the wrong place ? – haki Apr 23 '13 at 14:23
  • You're looking at a windows build. You need to look at the source. You can check it out from https://r-forge.r-project.org/scm/?group_id=118. [This post](http://stackoverflow.com/questions/11105131/cannot-install-r-forge-package-using-install-packages) might help. – GSee Apr 23 '13 at 14:36
  • This is the specific file: https://r-forge.r-project.org/scm/viewvc.php/pkg/xts/R/index.R?view=markup&root=xts – GSee Apr 23 '13 at 14:37
  • Well, my patch isn't right because I didn't `return` the `as.Date()` stuff, so if it works, it's by essentially removing the `if` statement which may break something else. There's more to it than I thought. You can follow the progress of this bug at https://r-forge.r-project.org/tracker/index.php?func=detail&aid=2577&group_id=118&atid=516 – GSee Apr 25 '13 at 13:56