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

Stephen Tucker brown_emu at yahoo.com
Sun Apr 1 06:03:22 CEST 2007

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")

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

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


#=== Plot 1 ===
# system TZ is in "Pacific Daylight Time"
# POSIXct object is in "Pacific Daylight Time"
dp <- seq(Sys.time(),len=10,by="day")
# Looks okay

#=== Plot 2 ===
# system TZ is in "Pacific Daylight Time"
# POSIXct object is in "GMT"
dp <- seq(Sys.time(),len=10,by="day")
# 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")
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

More information about the R-help mailing list