1

I have an XTS that is part of a list returns$sig and from that XTS, I pull out a set of elements based on some conditions and store the Index in a variable tstart.

> tstart <- index(returns$sig[which(returns$sig != lag(returns$sig,1) & returns$sig != 0)])
> length(tstart)
[1] 599

When I try and access the returns$sig XTS again with the dates in tstart, I get a XTS with a different length:

> length(returns$sig[tstart])
[1] 478

It should return something with length 599. If I try and access the XTS in a different way, I do get something of the same length:

> length(returns$sig[match(tstart,index(returns$sig))])
[1] 599

Spent hours on this and haven't found a resolution. Is there something obvious that I am doing wrong? And to make matters worse, I swear that length(returns$sig[tstart]) returned 599 yesterday and everything was working fine.

mchangun
  • 9,814
  • 18
  • 71
  • 101
  • 1
    If something was "working fine" yesterday, did you try closing your R session and re-running your commands? Otherwise, please do try to share some code that reproduces your problem. – A5C1D2H2I1M1N2O1R2T1 Nov 30 '12 at 08:57
  • @mrdwab Sorry for the poorly formed question. I couldn't reproduce the error with a short example and didn't want to post all my code. I have finally figured out the issue. It seems to be related to a [bug](http://stackoverflow.com/questions/13341104/why-does-xts-shift-a-date-one-day-back-when-creating-an-xts-object-from-a-data-f/13441865#comment18593616_13441865) some ppl have been reporting with XTS. All I needed to do was to specify a timezone for my system with `Sys.setenv(TZ = "GMT")` – mchangun Nov 30 '12 at 10:15
  • @mchangun: can you post that as an answer to your question? It would also be helpful if you specify which version of xts you're using. – Joshua Ulrich Nov 30 '12 at 13:57
  • @JoshuaUlrich Done. I am using xts_0.8-8 – mchangun Nov 30 '12 at 16:19

1 Answers1

0

Sorry for the poorly formed question. I couldn't reproduce the error with a short example and didn't want to post all my code. I have finally figured out the issue. It seems to be related to a bug some ppl (myself included) have been reporting with XTS. All I needed to do was to specify a timezone for my system with Sys.setenv(TZ = "GMT").

For those that are interested, I am using xts_0.8-8.

Community
  • 1
  • 1
mchangun
  • 9,814
  • 18
  • 71
  • 101
  • Do you still experience the problem with the R-Forge version (without having to set the TZ environment variable)? – GSee Nov 30 '12 at 17:04
  • The R-Forge version is "Current" so you should be able to install it with `install.packages("xts", repos="http://r-forge.r-project.org")`. If that doesn't work for some reason, see [this post](http://stackoverflow.com/questions/11105131/cannot-install-r-forge-package-using-install-packages) about building from source. – GSee Nov 30 '12 at 17:07
  • @GSee Thanks - before I try that, how do I revert to the current CRAN version of XTS? In case the R-Forge version has something in it that messes other stuff up. Thanks. – mchangun Dec 01 '12 at 10:16
  • Just install the CRAN version with `install.packages("xts")`, then that version will be used. – GSee Dec 01 '12 at 15:10
  • You can always use dput() on a subset of your _actual_ data and then modify with random data to protect the innocent. The central issue is indeed TZ. This will be fixed, but may not be yet - and key to fixing is reproducible reports. Dates as POSIXct in R translate from 1 "Date" to over 160 BILLION possible microseconds within that 'day' when you account for TZ settings. You can see the possible issues. – Jeff R Dec 02 '12 at 21:29
  • @GSee FYI, I still have the same problem with the R-Forge version of XTS. – mchangun Dec 03 '12 at 03:56