If I take the following simple data: YEAR MONTH DAY WEIGHT.KG 2003 10 6 1.2 2003 10 12 1.2 2003 10 16 1.3 and format the date data and plot it: dates <- strptime(paste(DAY,MONTH,YEAR),"%d%m%Y") plot(c(min(dates),max(dates)),c(0,max(WEIGHT.KG)), xlab="Date",ylab="Weight (kg)",type="n") lines(dates,WEIGHT.KG) points(dates,WEIGHT.KG) I find that the data points are all plotted at (x-1,y), where x is in days. Have I requested this behaviour accidentally? I'm using R-1.8 on OS X. Printing the dates object looks correct, and simple manipulations such as max(dates)-min(dates) behave normally. Jacob Etches Doctoral candidate Dept of Public Health Sciences University of Toronto
I am not seeing this on Linux. The x axis marks are at midnight GMT, hence 1am BST on my system. On Fri, 17 Oct 2003, Jacob Etches wrote:> If I take the following simple data: > > YEAR MONTH DAY WEIGHT.KG > 2003 10 6 1.2 > 2003 10 12 1.2 > 2003 10 16 1.3 > > and format the date data and plot it: > > dates <- strptime(paste(DAY,MONTH,YEAR),"%d%m%Y") > plot(c(min(dates),max(dates)),c(0,max(WEIGHT.KG)), > xlab="Date",ylab="Weight (kg)",type="n") > lines(dates,WEIGHT.KG) > points(dates,WEIGHT.KG) > > I find that the data points are all plotted at (x-1,y), > where x is in days. Have I requested this behaviour > accidentally? I'm using R-1.8 on OS X. > > Printing the dates object looks correct, and simple > manipulations such as max(dates)-min(dates) behave > normally. > > Jacob Etches > > Doctoral candidate > Dept of Public Health Sciences > University of Toronto > >-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
The problem is related to time zones. The easiest way to
handle this is to avoid using POSIXt and use chron instead
so you don't have to worry about them.
require(chron)
day <- 6:16
dts <- dates(paste("10", day, "03", sep="/"))
plot(dts,day)
abline(v=dts)
---
From: Jacob Etches <jetches at iwh.on.ca>
If I take the following simple data:
YEAR MONTH DAY WEIGHT.KG
2003 10 6 1.2
2003 10 12 1.2
2003 10 16 1.3
and format the date data and plot it:
dates <- strptime(paste(DAY,MONTH,YEAR),"%d%m%Y")
plot(c(min(dates),max(dates)),c(0,max(WEIGHT.KG)),
xlab="Date",ylab="Weight (kg)",type="n")
lines(dates,WEIGHT.KG)
points(dates,WEIGHT.KG)
I find that the data points are all plotted at (x-1,y),
where x is in days. Have I requested this behaviour
accidentally? I'm using R-1.8 on OS X.
Printing the dates object looks correct, and simple
manipulations such as max(dates)-min(dates) behave
normally.
Jacob Etches
Doctoral candidate
Dept of Public Health Sciences
University of Toronto
_______________________________________________
No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com
> From: Dirk Eddelbuettel <edd at debian.org> > > On Fri, Oct 17, 2003 at 01:16:00PM -0400, Gabor Grothendieck wrote: > > > > > > The problem is related to time zones. The easiest way to > > handle this is to avoid using POSIXt and use chron instead > > so you don't have to worry about them. > > > > require(chron) > > day <- 6:16 > > dts <- dates(paste("10", day, "03", sep="/")) > > plot(dts,day) > > abline(v=dts) > > I don't think I'd call that easiest. Jacob simply did not specify hour, > minute and second for a display where it mattered (mostly because he only > plotted 3 points, with 300 it would have close to impossible to discern). > > One way to address this would be to give a hour and minute as in > > dates <- strptime(paste(DAY,MONTH,YEAR,"23:59"),"%d %m %Y %H:%M") > > (where I also adjust the format string for the space paste() adds). > The three plot commands can also be combined into > > plot(dates,WEIGHT.KG, > ylim=c(0,max(WEIGHT.KG)), > xlab="Date",ylab="Weight (kg)",type="o")Unfortunately, that solution will not work in all time zones. For example, to get dates to line up in my time zone (Eastern Daylight Time) I would have to do this: day <- 6:16 dts <- strptime(paste(day,10,2003,"20:00"),"%d %m %Y %H:%M") plot(dts,day) abline(v=as.POSIXct(dts)) Its currently daylight savings time where I am but we are soon going to change to standard time for the winter which will force this to change shortly so even the above is not sufficient. Time zones are not part of the problem yet POSIXt forces this extraneous complication on you. chron has no time zones in the first place and therefore allows you to work in the natural frame of the problem, avoiding subtle problems like this. This sort of thing has been discussed a number of times and I had previously suggested that chron be moved to the base or else that a timezone-less version of POSIXt be added to the base. See: https://stat.ethz.ch/pipermail/r-devel/2003-August/027269.html (I am using R 1.7.1 on Windows 2000.) _______________________________________________ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com
I do see the described behavior, on three systems, linux R 1.8.0, Mac OS X R 1.8.0, and Solaris R 1.7.1. Plot 1 is different than plot 2; in plot 1 the points are offset to the left of the axis tick marks. datet <- as.POSIXct(dates) ## 1 plot(datet,WEIGHT.KG) ## 2 plot(datet,WEIGHT.KG,xaxt='n') axis.POSIXct(1,at=datet) To investigate a bit, I made a copy of axis.POSIXct and modified it slightly to return the value of "at" that it calculates. I get this: "2003-10-06 17:00:00 PDT" "2003-10-08 17:00:00 PDT" "2003-10-10 17:00:00 PDT" "2003-10-12 17:00:00 PDT" "2003-10-14 17:00:00 PDT" These are equal to midnight GMT, since my systems are currently in PDT, i.e. GMT-7.> version_ platform powerpc-apple-darwin6.7.5 arch powerpc os darwin6.7.5 system powerpc, darwin6.7.5 status Patched major 1 minor 8.0 year 2003 month 10 day 13 language R> version_ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status Patched major 1 minor 8.0 year 2003 month 10 day 16 language R> version_ platform sparc-sun-solaris2.7 arch sparc os solaris2.7 system sparc, solaris2.7 status major 1 minor 7.1 year 2003 month 06 day 16 language R -Don At 9:21 AM -0400 10/17/03, Jacob Etches wrote:>If I take the following simple data: > >YEAR MONTH DAY WEIGHT.KG >2003 10 6 1.2 >2003 10 12 1.2 >2003 10 16 1.3 > >and format the date data and plot it: > >dates <- strptime(paste(DAY,MONTH,YEAR),"%d%m%Y") >plot(c(min(dates),max(dates)),c(0,max(WEIGHT.KG)), > xlab="Date",ylab="Weight (kg)",type="n") > lines(dates,WEIGHT.KG) > points(dates,WEIGHT.KG) > >I find that the data points are all plotted at (x-1,y), >where x is in days. Have I requested this behaviour >accidentally? I'm using R-1.8 on OS X. > >Printing the dates object looks correct, and simple >manipulations such as max(dates)-min(dates) behave >normally. > >Jacob Etches > >Doctoral candidate >Dept of Public Health Sciences >University of Toronto > > >______________________________________________ >R-help at stat.math.ethz.ch mailing list >https://www.stat.math.ethz.ch/mailman/listinfo/r-help-- -------------------------------------- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA
At Friday 02:20 PM 10/17/2003 -0400, Gabor Grothendieck wrote:>[material deleted] >Time zones are not part of the problem yet POSIXt forces this >extraneous complication on you. chron has no time zones in the >first place and therefore allows you to work in the natural frame >of the problem, avoiding subtle problems like this. > >This sort of thing has been discussed a number of times and I >had previously suggested that chron be moved to the base or else that >a timezone-less version of POSIXt be added to the base. See: >https://stat.ethz.ch/pipermail/r-devel/2003-August/027269.htmlI also see the usefulness of a time-zone-free time/date class, but why does "chron" need to be moved to the base to be useful here? -- Tony Plate
From: Tony Plate <tplate at blackmesacapital.com>> I also see the usefulness of a time-zone-free time/date class, > but why does "chron" need to be moved to the base to be useful here?Because other software makes use of times in the base. Package writers figure that what is in the base is the most available and used so that is what they use. Thus classes in the base get propagated throughout the libraries too. _______________________________________________ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com
Yes. The timezone is not the whole problem. What one would really like is that plot understands that it is being given daily data and acts accordingly, in the same way that plot already understands that its being given a factor object or a dendogram, etc. and produces the right plot. The OO way would be that the data describes itself, "telling" plot what it is being given so that plot can make the right choice. --- Date: Fri, 17 Oct 2003 20:47:17 +0100 (BST) From: Prof Brian Ripley <ripley at stats.ox.ac.uk> [ Add to Address Book | Block Address | Report as Spam ] To: Don MacQueen <macq at llnl.gov> Cc: Jacob Etches <jetches at iwh.on.ca>, <r-help at stat.math.ethz.ch> Subject: Re: [R] datetime data and plotting So someone forgot to specify the timezone, if the current one was not wanted. However, I don't see how timezones can account for a 24hour difference as originally reported. On Fri, 17 Oct 2003, Don MacQueen wrote:> I do see the described behavior, on three systems, linux R 1.8.0, Mac > OS X R 1.8.0, and Solaris R 1.7.1. > Plot 1 is different than plot 2; in plot 1 the points are offset to > the left of the axis tick marks. > > datet <- as.POSIXct(dates) > > ## 1 > plot(datet,WEIGHT.KG) > > ## 2 > plot(datet,WEIGHT.KG,xaxt='n') > axis.POSIXct(1,at=datet) > > To investigate a bit, I made a copy of axis.POSIXct and modified it > slightly to return the value of "at" that it calculates. I get this: > "2003-10-06 17:00:00 PDT" "2003-10-08 17:00:00 PDT" > "2003-10-10 17:00:00 PDT" "2003-10-12 17:00:00 PDT" > "2003-10-14 17:00:00 PDT"Have you heard of debug()?> These are equal to midnight GMT, since my systems are currently in > PDT, i.e. GMT-7.-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 _______________________________________________ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com