[R-SIG-Finance] Dates not formatting properly for quarterly time series in xtsExtra

[R. Michael Weylandt]

On Mon, Jan 6, 2014 at 7:25 PM, Eric Zivot <ezivot at u.washington.edu> wrote:
> I have been working on some examples of plotting time series for my new book
> Modeling Financial Time Series with R and I noticed something funny with
> plot.xts() from the R package xtsExtra when trying to plot quarterly time
> series created from the xts function to.quarterly. Here is an example:
>
>> sessionInfo()
>
> R version 3.0.2 (2013-09-25)
>
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
>> getSymbols("GS")
>
>> GS.Ad.xts = Ad(GS)
>> GS.Ad.quarterly.xts = to.quarterly(GS.Ad.xts, OHLC=FALSE)
>> periodicity(GS.Ad.quarterly.xts)
> Quarterly periodicity from 2007 Q1 to 2014 Q1
>> # Error in axis format for time plot
>> plot(GS.Ad.quarterly.xts, lwd=2, col="blue")
>
> In the resulting plot, the format for the axis is not correct. Instead of
> showing the date as "Q1 2007", I see "%b 2007".

Hi Professor,

Thanks for the great bug report. Very easy to track down exactly what happened.

The issue is in xts, not xtsExtra: specifically, the axTicksByTime() function.

> axTicksByTime(GS.Ad.quarterly.xts)[1:5]
%n%b%n2007 %n%b%n2007 %n%b%n2007 %n%b%n2007 %n%b%n2008
         1          2          3          4          5

(I'm on a Unix system, hence the extra %n symbols)

Looking at the source of axTicksByTime, one sees that the default
formatting is "%b %Y" but that weekly, daily, minutely [1], hourly,
secondly [1] periodicities are special-cased.

Unfortunately, the "yearqtr" index object doesn't have anything which
can be formatted at %b (month name in English in ?strptime), so the %b
remains, giving the ugly axes you see.

Adding this line to the source of axTicksByTime (say around L40) should fix it:

if(time.scale == "quarterly") fmt <- "%Y-Q%q"

I've pushed a commit to r-forge which adds this to a copy of
axTicksByTime in xtsExtra which should fix it temporarily [r800]. I'll
speak to Josh about putting in xts-proper.

Hope it helps,
Michael

[1] Neither of those actually seem like the right word.

>
> Also, I notice a strange error related to timezones.
>
I think this is just a warning (at least on my system): shouldn't be a
problem if you're on daily-or-lower data.

>
>
>> Sys.timezone()
> [1] "PST"
>
>
>
> Do I have to change my system timezone to UTC prior to downloading the data
> to get rid of this error?
>
> Thanks for any help.
>