[R] plotting POSIXct objects {was Re: Using split() several times in a row?}

[Gabor Grothendieck]

I think you are right.  Plot does seem to have changed and maybe its due to
a change in plot or maybe due to a change in some routine it in turn calls.
Here is another test:

dd <- ISOdatetime(2007, 1, 1:3, 0, 0, 0, tz = "")
plot(dd, 1:3)

dd.gmt <- ISOdatetime(2007, 1, 1:3, 0, 0, 0, tz = "GMT")
plot(dd.gmt, 1:3)


On 4/1/07, Stephen Tucker <brown_emu at yahoo.com> wrote:
> Hi Gabor and Martin,
>
> Thanks very much for the information. (and Gabor for the Fold() routine
> included in original reply)
>
> Regarding changes, I wonder if the behavior of plot() on POSIXct objects
> changed also. According to Rnews Vol. 4/1, p. 31,
>
> =====
> dp <- seq(Sys.time(),len=10,by="day")
> plot(dp,1:10)
>
> This does not use the current wall clock time
> for plotting today and the next 9 days since
> plot treats the datetimes as relative to GMT.
> The x values that result will be off from the wall
> clock time by a number of hours equal to the
> difference between the current time zone and
> GMT.
> =====
>
> In R 2.4.0, the x-values match up with the times I put in it (on Pacific
> Daylight Time, which is what my system is on). However, when I convert the
> times to GMT, they are shifted behind by 7hrs. Seems plot() is treating
> datetimes relative to the system time and not GMT? Please see three examples
> below... I tried to look at version update notes but could I have missed this
> one?
>
> Stephen
>
> #=== Plot 1 ===
> # system TZ is in "Pacific Daylight Time"
> # POSIXct object is in "Pacific Daylight Time"
> dp <- seq(Sys.time(),len=10,by="day")
> plot(dp,1:length(dp))
> # Looks okay
>
> #=== Plot 2 ===
> # system TZ is in "Pacific Daylight Time"
> # POSIXct object is in "GMT"
> dp <- seq(Sys.time(),len=10,by="day")
> plot(as.POSIXct(format(dp),"GMT"),1:length(dp))
> # Shifted by 7 hours
>
> #=== Plot 3 ===
> # system TZ is in "GMT"
> # POSIXct object is in "GMT"
> Sys.putenv(TZ = "GMT")
> dp <- seq(Sys.time(),len=10,by="day")
> plot(dp,1:length(dp))
> Sys.putenv(TZ = "")
> # Looks okay
>
>
> --- Gabor Grothendieck <ggrothendieck at gmail.com> wrote:
>
> > On 3/31/07, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
> > > >>>>> "SteT" == Stephen Tucker <brown_emu at yahoo.com>
> > > >>>>>     on Fri, 30 Mar 2007 18:41:39 -0700 (PDT) writes:
> > >
> > >  [..]
> > >
> > >    SteT> For dates, I usually store them as "POSIXct" classes
> > >    SteT> in data frames, but according to Gabor Grothendieck
> > >    SteT> and Thomas Petzoldt's R Help Desk article
> > >    SteT> <http://cran.r-project.org/doc/Rnews/Rnews_2004-1.pdf>,
> > >    SteT> I should probably be using "chron" date and times...
> > >
> > > I don't think you should (and I doubt Gabor and Thomas would
> > > recommend this in every case):
> > >
> > > POSIXct (and 'POSIXlt', 'POSIXt' & 'Date') are part of standard R,
> > > and whereas they may seem not as convenient in all cases as "chron"
> > > etc, I'd rather recommed to stick to them in such a case.
> >
> > There is one change that has occurred since the article that in my
> > mind would let you safely use POSIX but its pretty drastic.  At the time
> > of the article you could not set the time zone to GMT in the R process
> > on Windows but now you can do this:
> >
> > Sys.putenv(TZ = "GMT")
> >
> > and you can also change it back like this:
> >
> > Sys.putenv(TZ = "")
> >
> > Since the problem is that you never can be sure which time zone the
> > time is interpreted in within various function (although you can be pretty
> > sure its either the local time zone or GMT) by setting the process to
> > GMT you make the two alternatives the same so it no longer matters.
> >
> > Short of the above, the recommendations of the article should be followed.
> > Its not a matter of convenience.  Its a matter of being error prone
> > and introducing
> > subtle time-zone related errors into your code which are very hard to track
> > down or worse, even realize that you have.
> >
> > Those who claim that its not a problem simply have not used dates and times
> > enough or they would not say that.  I have seen posters make such comments
> > on this list only later to run into subtle time zone problems that they
> > never
> > would have had had they followed the advice in the article.
> >
> > I've used R and dates a lot and therefore have made a lot of programming
> > errors
> > and these recommendations come from bitter experience looking back to see
> > how I could have avoided them.
> >
> > ______________________________________________
> > R-help at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide
> > http://www.R-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
> >
>
>
>
>
> ____________________________________________________________________________________
> Don't get soaked.  Take a quick peek at the forecast
> with the Yahoo! Search weather shortcut.
> http://tools.search.yahoo.com/shortcuts/#loc_weather
>