Question

I would like to extract the dates from a time series obtained using getSymbols
but when I used the index / index.xts function the returned dates appear to be one day earlier.
I cannot understand why this behavior happens in the following code.

However, the intended behavior is to obtain a list of Date object corresponding to the one in the original time series.

Here is the code, note the last date of the time series SPY is 24 Aug 2012 but the last value from the index(SPY) call is 23 Aug 2012:

getSymbols("SPY")

tail(SPY)

    SPY.Open SPY.High SPY.Low SPY.Close SPY.Volume SPY.Adjusted
2012-08-17   142.23   142.30  141.86    142.18   90813700       142.18
2012-08-20   141.98   142.22  141.59    142.19   78255700       142.19
2012-08-21   142.54   143.09  141.45    141.76  105581100       141.76
2012-08-22   141.40   142.05  141.07    141.82  132999200       141.82
2012-08-23   141.47   141.48  140.44    140.66  111406800       140.66
2012-08-24   140.31   141.83  140.22    141.51   99431500       141.51 

tail(index(SPY))

[1] "2012-08-16" "2012-08-19" "2012-08-20" "2012-08-21" "2012-08-22" "2012-08-23"

tail(index.xts(SPY))

[1] "2012-08-16" "2012-08-19" "2012-08-20" "2012-08-21" "2012-08-22" "2012-08-23"

Thank you to everybody that could reply to my post.

Additional info on the session

>sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: i386-pc-mingw32/i386 (32-bit)

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

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

other attached packages:
 [1] rbenchmark_0.3.1             fGarch_2110.80.1            
 [3] fBasics_2160.81              MASS_7.3-20                 
 [5] timeSeries_2160.95           timeDate_2160.95            
 [7] tseries_0.10-29              quadprog_1.5-4              
 [9] PerformanceAnalytics_1.0.4.4 quantstrat_0.6.8            
[11] blotter_0.8.10               FinancialInstrument_0.15.2  
[13] quantmod_0.3-17              TTR_0.21-1                  
[15] Defaults_1.1-1               xts_0.8-6                   
[17] zoo_1.7-7                    lubridate_1.1.0             
[19] stringr_0.6.1                plyr_1.7.1                  
[21] XML_3.9-4.1                 

loaded via a namespace (and not attached):
 [1] colorspace_1.1-1   dichromat_1.2-4    digest_0.5.2       ggplot2_0.9.1     
 [5] grid_2.15.1        labeling_0.2       lattice_0.20-6     memoise_0.1       
 [9] munsell_0.3        proto_0.3-9.2      RColorBrewer_1.0-5 reshape2_1.2.1    
[13] scales_0.2.1       stabledist_0.6-4   tools_2.15.1     


> getDefaults(getSymbols)
NULL
> getSymbolLookup("SPY")
NULL
> showSymbols()
 SPY     GSPC      IBM      XLF      XLP      XLE      XLY      XLV      XLI 
 "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo" 
     XLB      XLK      XLU      IEF     AAPL      DIA     MSFT      IWM      EEM 
 "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo" 
     EFA      GLD      AGG      HYG      FXE      FXY      VXX      VXZ      HIG 
 "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo"  "yahoo" 
    VTI      VEU      VNQ      DBC      XAU     gold     Gold STOXX50E     GOLD 
"yahoo"  "yahoo"  "yahoo"  "yahoo"  "oanda"  "oanda"  "oanda"  "yahoo"  "yahoo" 
     VIX  DEXUSEU   EURUSD  DEXKOUS    EUR=X    INR=X 
 "yahoo"   "FRED"  "oanda"   "FRED"  "yahoo"  "yahoo" 

Also note that I have installed some R code from the Systematic Investor blog, systematicinvestor.wordpress.com, by using the commands

setInternet2(TRUE)
con = gzcon(url('systematicportfolio.com/sit.gz', 'rb'))
source(con) 
close(con) 

SOLUTION PLUS ADDITIONAL QUESTION

GSee user found the answer (Thank you!) pointing out that in my session I have masked index.xts. So a solution is to call xts:::index.xts(SPY) instead of just index.xts(SPY) to override the masking.
In fact the command

> tail(xts:::index.xts(SPY)) 

returns the right answer

[1] “2012-08-17” “2012-08-20” “2012-08-21” “2012-08-22” “2012-08-23” “2012-08-24” –

The answer now prompted another question: given below the code for the “masking/overriding” index.xts function (that returns the wrong answer moving the dates one day earlier):

> index.xts
function (
x           # XTS object
)
{
temp = attr(x, 'index')
class(temp)='POSIXct'   
if( attr(x, '.indexCLASS')[1] == 'Date')
    temp = as.Date(temp)
return(temp)
}

Why is this function returning the wrong results when called as tail(index.xts(SPY)) ? What is wrong with the code of this index.xts function?

Compare the two output (the first one is wrong while the second provide the right answer):

tail(index.xts(SPY))

[1] "2012-08-16" "2012-08-19" "2012-08-20" "2012-08-21" "2012-08-22" "2012-08-23"

tail(xts:::index.xts(SPY))
[1] "2012-08-17" "2012-08-20" "2012-08-21" "2012-08-22" "2012-08-23" "2012-08-24"

Thanks again for your time and attention.

Answer 1

This issue is that you have run some code that masks the index.xts method from the xts package. In the comments of your OP, you told us you ran this code

setInternet2(TRUE)
con = gzcon(url('http://www.systematicportfolio.com/sit.gz', 'rb'))
source(con)
close(con)

After running that code, index.xts has been redefined (actually, masked) to be

> index.xts
function
(
        x                       # XTS object
)
{
        temp = attr(x, 'index')
        class(temp)='POSIXct' 

        if( attr(x, '.indexCLASS')[1] == 'Date')
                temp = as.Date(temp)
        return(temp)
}

If you compare that to the xts:::index.xts function that is being masked, you can see that it is quite different. So, you can no longer expect the same results.

If you download the code from systematicportfolio.com/sit.gz, and look at it, you’ll see this comment

###############################################################################
# Fast alternative to index(x) for XTS object
# NOTE index.xts is the same name as the index function in the XTS package
###############################################################################

So, it appears that the author did this intentionally in hopes of making it faster. Unfortunately, he has also made it less robust.

This code actually gives me the same result as xts:::index.xts, so I’m not 100% certain of why you’re getting different results using it. But, my guess is that it has to do with changing the class from numeric to POSIXct and then converting back to Date

Anyway, I’d probably run

rm(index.xts)

after sourcing that code to remove this “enhancement.”