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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > On 3/31/07, Martin Maechler <[EMAIL PROTECTED]> wrote: > > > >>>>> "SteT" == Stephen Tucker <[EMAIL PROTECTED]> > > > >>>>> 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@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 > ______________________________________________ R-help@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.