time zones, daylight saving etc.
Yes, I did mention the OS was unstated, knowing that some had problems. I will try to investigate why this is not working on Windows for a future release. For Windows users something like .../RGui.exe TZ=GMT should do it.
On Thu, 12 May 2005, Vadim Ogranovich wrote:
Works for me on Linux:
Sys.time()
[1] "2005-05-12 10:22:31 PDT"
Sys.putenv(TZ="GMT") Sys.time()
[1] "2005-05-12 17:22:37 GMT" I extensively use the reset of TZ to parse times.
-----Original Message----- From: r-help-bounces at stat.math.ethz.ch [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Gabor Grothendieck Sent: Thursday, May 12, 2005 6:18 AM To: Prof Brian Ripley Cc: Carla Meurk; r-help at stat.math.ethz.ch Subject: Re: [R] time zones, daylight saving etc. I have tried this but on Windows XP R 2.1.0 found I had to set it outside of R prior to starting R. 1. unsuccessful
Sys.time()
[1] "2005-05-12 09:08:03 Eastern Daylight Time"
Sys.putenv(TZ="GMT") Sys.time() # no change
[1] "2005-05-12 09:08:12 Eastern Daylight Time" 2. OK C:\>set tz=GMT C:\>start "" "\Program Files\R\rw2010\bin\r.exe" R : Copyright 2005, The R Foundation for Statistical Computing Version 2.1.0 Patched (2005-04-18), ISBN 3-900051-07-0 R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for a HTML browser interface to help. Type 'q()' to quit R.
Sys.time()
[1] "2005-05-12 13:10:58 GMT" I assume it could be set in .Renviron but it would be nice if one could set it right from within R so that one can write a function that sets it, does processing and then sets it back. Don't know if this is possible. On 5/12/05, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
Would it not just be easier to set the timezone to GMT for the duration of the calculations? I don't see an OS mentioned
here, but
on most TZ=GMT for the session will do it. On Thu, 12 May 2005, Rich FitzJohn wrote:
Hi, seq.dates() in the chron package does not allow creating
sequences
by minutes, so you'd have to roll your own sequence generator. Looks like the tzone attribute of the times is lost when using min(), max() and seq(). You can apply it back manually, but it does not affect the calculation, since POSIXct times are stored as seconds since 1/1/1970 (?DateTimeClasses). ## These dates/times just span the move from NZDT to NZST: dt.dates <- paste(rep(15:16, c(5,7)), "03", "2003", sep="/") dt.times <- paste(c(19:23, 0:6), "05", sep=":") dt <- paste(dt.dates, dt.times) ## No shift in times, or worrying about daylight savings; appropriate ## iff the device doing the recording was not itself adjusting for ## daylight savings, presumably. datetime <- as.POSIXct(strptime(dt, "%d/%m/%Y %H:%M"), "GMT") ## Create two objects with all the times in your range,
one with the
## tzone attribute set back to GMT (to match datetimes),
and one ##
without this.
mindata1 <- mindata2 <- seq(from=min(datetime), to=max(datetime),
by="mins") attr(mindata2, "tzone") <-
"GMT"
fmt <- "%Y %m %d %H %M"
## These both do the matching correctly:
match(format(datetime, fmt), format(mindata1, fmt, tz="GMT"))
match(format(datetime, fmt), format(mindata2, fmt, tz="GMT"))
## However, the first of these will not, as it gets the
timezone all
## wrong, since it's neither specified in the call to
format(), or
as ## an attribute of the POSIXct object. match(format(datetime, fmt), format(mindata1, fmt)) match(format(datetime, fmt), format(mindata2, fmt)) ## It is also possible to run match() directly off the POSIXct object, ## but I'm not sure how this will interact with
things like
leap ## seconds: match(datetime, mindata1) Time zones do my head in, so you probably want to check this all pretty carefully. Looks like there's lots of gotchas (e.g. subsetting a POSIXct object strips the tzone attribute). Cheers, Rich On 5/12/05, Gabor Grothendieck <ggrothendieck at gmail.com> wrote:
You could use the chron package. It represents date
times without
using time zones so you can't have this sort of problem. On 5/10/05, Carla Meurk <ksm32 at student.canterbury.ac.nz> wrote:
Hi, I have a whole bunch of data, which looks like:
15/03/2003 10:20 1
15/03/2003 10:21 0
15/03/2003 12:02 0
16/03/2003 06:10 0
16/03/2003 06:20 0.5
16/03/2003 06:30 0
16/03/2003 06:40 0
16/03/2003 06:50 0
18/03/2003 20:10 0.5
etc. (times given on a 24 hour clock)
and goes on for years. I have some code:
data<-read.table("H:/rainfall_data.txt",h=T)
library(survival)
datetime <- as.POSIXct(strptime(paste(data$V1,
data$V2), "%d/%m/%Y
%H:%M"), tz="NZST") which produces: [10] "2003-03-13 21:13:00 New Zealand Daylight Time" [11] "2003-03-15 13:20:00 New Zealand Daylight Time" [12] "2003-03-15 22:20:00 New Zealand Daylight Time" [13] "2003-03-15 22:21:00 New Zealand Daylight Time" [14] "2003-03-16 00:02:00 New Zealand Daylight Time" [15] "2003-03-16 18:10:00 New Zealand Standard Time" [16] "2003-03-16 18:20:00 New Zealand Standard Time" [17] "2003-03-16 18:30:00 New Zealand Standard Time" My problem is that "15/03/2003 12:02" has become
"16/03/2003 00:02"
i.e. it is 12 hours behind (as is everything else),
but also, I
do not want to change time zones. The 12 hour delay is not really a problem just an
annoyance, but
the time zone change is a problem because later on I
need to match
up data by time using mindata<-seq(from=min(datetime),to=max(datetime),by="mins") newdata<-matrix(0,length(mindata),1) newdata[match(format.POSIXct(datetime,"%Y %m %d %H %M"),format.POSIXct(mindata,"%Y %m %d %H %M"))]<-data$V3 and things go wrong here with matching repeating times/missing times around the timezone changes and, my resulting vector is 1 hour shorter than my other series. From the R help I
see that my
OS may be to blame but, even if I specify tz="GMT" I still get NZST and NZDT. Can someone help? I hope this all makes sense Carla
______________________________________________ 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
______________________________________________ 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
-- Rich FitzJohn rich.fitzjohn <at> gmail.com |
You are in a maze of twisty little
functions,
all alike
______________________________________________ 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
-- 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
______________________________________________ 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
______________________________________________ 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
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