Hmmm works fine for me.
xts(1, order.by = strptime(04/05/87 2:00,format=%m/%d/%y %H:%M))
[,1]
1987-04-05 02:00:00 1
Maybe an old version of xts? I am using xts version 0.8-0. (you can check that
with sessionInfo().)
Regards,
Wolfgang Wu
- Ursprüngliche Message -
Von: Dan
Thank you Wolfgang. On my machine sessionInfo shows I am using xts
version 0.8-2 -
I think it is the latest one, see
http://cran.r-project.org/web/packages/xts/index.html
Maybe someone can confirm correct operation in 0.8-2. Could this be a
Revo/base R version issue?
sessionInfo()
R version
hmmm.
I'm using xts_0.8-3 revision 602 on R-Forge, and it *almost* works for me,
but the time is off by an hour
xts(1, order.by=strptime(04/05/87 2:00,format=%m/%d/%y %H:%M))
[,1]
1987-04-05 01:00:001
-Garrett
On Fri, Sep 23, 2011 at 7:33 AM, Dan Potter
It is something within strptime and/or as.POSIXct. Basically POSIXct
is causing some issue, somewhere. In my TZ America/Chicago I see:
strptime(04/05/87 2:00,format=%m/%d/%y %H:%M)
[1] 1987-04-05 02:00:00 CDT
as.POSIXct(strptime(04/05/87 2:00,format=%m/%d/%y %H:%M))
[1] 1987-04-05 01:00:00
Dan,
This is probably an issue with the start/end of daylight saving time
in your timezone.
Best,
--
Joshua Ulrich | FOSS Trading: www.fosstrading.com
On Fri, Sep 23, 2011 at 7:38 AM, G See gsee...@gmail.com wrote:
hmmm.
I'm using xts_0.8-3 revision 602 on R-Forge, and it *almost* works
Thank you Jeff and Josh, that was very helpful. Other systems I have
worked with haven't included embedded daylight savings magic. (And I'm
not sure I like it unless I can compute time differences and durations
correctly when using it.)
My data (and many datasets I have work with) are UTC
Hi Dan,
I think it is a platform issue. Windows has been problematic around
the edges of TZ behavior - forever. Sys.timezone() and
Sys.getenv(TZ) even behave differently from time to time. I would
recommend the latter over the former. And non-windows above all ;-)
That said, I think you are
