4

I'm using the quantmod package to fetch stock data. The code

Data = getSymbols('LON:ADN',src="google",auto.assign=FALSE, from = '2011-08-10')

Results in an xts as expected, however on closer examination it shows a volume of trades for 2012-10-21 (October 21st) which was a sunday, and is therefore clearly erroneous. Several other sundays are also included. Unfortunately the errors surrounding the weekends seem to have moved the rest of the data out of alignment.

Has anyone experienced similar problems fetching tickers with quantmod before, and if so, are they aware of a way around them?

Thanks

Joshua Ulrich
  • 173,410
  • 32
  • 338
  • 418
N. McA.
  • 4,796
  • 4
  • 35
  • 60
  • I am using the latest version (0.3-17) of the `quantmod` package and I am not having your problem. I get data for 2012-10-19 and the next one is 2012-10-22. Maybe you are not using the latest version? You can check by running `installed.packages()["quantmod", "Version"]`. – flodel Dec 22 '12 at 01:50
  • I don't replicate the problem either (`library(lubridate);unique(wday(Data, label=T))` shows no weekend days). I would check for a timezone error shifting your date. This is a common issue with POSIXct since they are datetime representations and dates without times are represented as midnight. Thus, if a function converts timezones you can shift days. – MattBagg Dec 22 '12 at 02:07
  • I've run into this problem before - actually fairly constantly in recent memory. I once found a web page that described the situation, which I'll try to find again. – BenBarnes Dec 22 '12 at 08:05
  • The timezone shifting sounds like the source, I'm on London time. What timezones are those who couldn't replicate the problem on? Also, do we think the shifting happening within the getsymbols call? The code above is all I'm running to produce the error. – N. McA. Dec 22 '12 at 08:39
  • Have a look at [this answer](http://stackoverflow.com/a/13441865/1281189) (including the comments) that suggests this is a timezone issue. However, after installing the r-forge version of `xts`, I still get data from Sundays. – BenBarnes Dec 22 '12 at 08:39
  • Thanks Mr. Barnes, I'll look into that. @flodel I've got quantmod 0.3-17 installed, I just checked. I could still do with knowing what time zones people with working versions are in. Thanks all. – N. McA. Dec 22 '12 at 09:17
  • If I may be a bit off-topic, in my experience yahoo's data is better than google's. Not that it will fix this problem, but to get the data from yahoo you could do `getSymbols('ADN.L',src="yahoo",auto.assign=FALSE, from = '2011-08-10')`. Is there an advantage to using google? – GSee Dec 22 '12 at 16:16
  • @ GSee Yep - Google's data is available closer to the end of the trading day, but is still free. – N. McA. Dec 23 '12 at 00:05

1 Answers1

3

As you mentioned in the comments, this looks like a timezone issue, possibly due to POSIX date conversion in the xts function (see this answer).

I am able to reproduce the issue in a fresh R session when Sys.getenv("TZ") is an empty character string. Setting the timezone to any valid timezone (not all tested), for example, "America/Chicago" yields expected dates, i.e., no Sundays:

In a fresh session (December 16th 2012 was a Sunday):

Sys.getenv("TZ")
# [1] ""

library(quantmod)
Data <- getSymbols('LON:ADN',src="google",auto.assign=FALSE, from = '2011-08-10')
tail(index(Data))
# [1] "2012-12-13" "2012-12-16" "2012-12-17" "2012-12-18" "2012-12-19" "2012-12-20"

Then change the timezone

Sys.setenv(TZ="America/Chicago")

Data <- getSymbols('LON:ADN',src="google",auto.assign=FALSE, from = '2011-08-10')
tail(index(Data))
# [1] "2012-12-14" "2012-12-17" "2012-12-18" "2012-12-19" "2012-12-20" "2012-12-21"

No Sundays.

Community
  • 1
  • 1
BenBarnes
  • 19,114
  • 6
  • 56
  • 74
  • Thanks for your help, but I just checked - all that needs to be done is setting Sys.getenv("TZ") to a valid time-zone. Could you edit your answer to make that really clear and help the future confused? Cheers – N. McA. Dec 22 '12 at 09:22
  • @N.McA., good pointer. Updated and removed part about r-forge, which did not fix the issue. – BenBarnes Dec 22 '12 at 09:34
  • This should be fixed in the R-forge version (quantmod v0.3-22) – Jeff R Dec 23 '12 at 11:41