search for: tzone

The documentation for the POSIXlt class states '"POSIXlt" objects will often have an attribute "tzone", a character vector of length 3 giving the time zone name from the TZ environment variable and the names of the base time zone and the alternate (daylight-saving) time zone. Sometimes this may just be of length one, giving the time zone <http://127.0.0.1:25207/library/base/help/time%20zone...

...ort. In R-devel, all.equal.POSIXt() by default > reports inconsistent time zones. Previously, > > > x <- Sys.time() > > all.equal(x, as.POSIXlt(x, tz = "EST5EDT")) > > would return TRUE. To ignore the time zone attributes in R-devel, the > argument 'check.tzone = FALSE' needs to be used. > > That said, I can reproduce the 'make check' failure in R-devel on Ubuntu > Linux when TZ is set, even if it is set to the system time zone: > > $ export TZ=Europe/Berlin > $ make check > [...] > > running code in '../../tests...

...ributes(as.POSIXlt(x)) $names [1] "sec" "min" "hour" "mday" "mon" "year" "wday" "yday" [9] "isdst" "zone" "gmtoff" $class [1] "POSIXlt" "POSIXt" $tzone [1] "US/Eastern" "EST" "EDT" > all.equal(x, as.POSIXlt(x)) [1] TRUE On R Under development (unstable) (2020-10-01 r79286) I get > x = Sys.time() > all.equal(x,x) [1] TRUE > attributes(as.POSIXlt(x)) $names [1] "sec" "min"...

Hello: What is the recommended method for retaining the tzone attributes when concatonating POSIXct objects? > (d1 <- ISOdate(1970,1,1)) # Sets the tzone attribute = GMT [1] "1970-01-01 12:00:00 GMT" > (d1.2 <- c(d1, d1)) # c(..) strips the tzone attribute, displays in the time zone of the operating system [1] "1970-01-01 04:00:0...

Yes, you are absolutely right and I'm pretty sure this will be fixed in one way or another. IMO, the failing test should simply use all.equal.POSIXt's new argument check.tzone=FALSE. Two simple alternatives modifying all.equal.POSIXt behaviour: - make check.tzone=FALSE the default: this is inconsistent with other arguments of all.equal methods, always defaulting to stricter checks - let all.equal.POSIXt generally ignore the tzone difference if tzone is unset for one o...

...on a typo in a time zone name: Irtutsk should be Irkutsk. A patch is attached. I also checked that this is the only bug of its kind in this file, i.e., all the other Olson time zones occurring in the file can also be found in Unicode Common Locale Data Repository. - Mikko Korpela Index: src/extra/tzone/registryTZ.c =================================================================== --- src/extra/tzone/registryTZ.c (revision 74465) +++ src/extra/tzone/registryTZ.c (working copy) @@ -303,7 +303,7 @@ { L"Russia Time Zone 4", "Asia/Yekaterinburg" }, { L&quo...

...-04-02 01:00:00 PST" [3] NA "2006-04-02 03:00:00 PDT" [5] "2006-04-02 04:00:00 PDT" "2006-04-02 05:00:00 PDT" I presume it gets PST/PDT from my (Windows) system; I can't set it with > force_tz(ymd_hms("2007-03-11 01:00:00"),tzone="PST") (from the lubridate package), but see > force_tz(ymd_hms("2006-04-02 01:00:00"),tzone="America/Los_Angeles") [1] "2006-04-02 01:00:00 PST" What I'd like to do is keep all the time in standard time so I don't lose the 2 a.m. data. Presumab...

...below. My input is actually an XL file, but the weird results below correctly model what I am seeing in my program. Before I punt and use lubridate or timeDate, could anyone please help me understand why POSIXct forces my variable back to GMT? I suspect that I'm not properly coding the tzone value, but it does not throw an error as-is. > tstamp <- "2011-05-22 11:45:00 MDT" > mode(tstamp) [1] "character" > > dateP <- as.POSIXct(tstamp, origin="1970-01-01", tzone="MDT") > mode(dateP) [1] "numeric" >...

R developers, The "tzone" attribute is stripped from a POSIXct object when the subscript command is called ("[.POISXct"). This results in dates being printed in the locale specific format after a subscript operation is applied to a POSIXct object which has cause several problems for me in the past. Here is...

...n (side, x, at, format, labels = TRUE, ...) +my.axis.POSIXct <- function (side, x, at, format, labels = TRUE, ...) { mat <- missing(at) || is.null(at) if (!mat) @@ -9,6 +9,7 @@ else 3:4] d <- range[2] - range[1] z <- c(range, x[is.finite(x)]) + attr(z, "tzone") <- attr(x, "tzone") if (d < 1.1 * 60) { sc <- 1 if (missing(format)) @@ -41,6 +42,7 @@ zz <- pretty(z/sc) z <- zz * sc class(z) <- c("POSIXt", "POSIXct") + attr(z, "tzone") <...

...ata into the local time zone (including daylight time) of my machine. Setting the tz="UTC" or "GMT" inside strptime seems to be ignored. I made the following cumbersome work around: foo$date=strptime((paste(yr,DOY), 0, 0), format="%Y %j %H %M",tz="") + 0 tzone.err=as.numeric(as.POSIXct(format(Sys.time(),tz="GMT"))-as.POSIXct(format(Sys.time(),tz="")))*3600 foo$date=foo$date-tzone.err attributes(foo$date)$tzone="GMT" Am I missing something obvious or is this a problem with Windoze? 2) Once I have the data in GMT, I try to p...

...o impractically slow to be a standard feature. On October 10, 2024 6:46:19 AM PDT, Jan van der Laan <rhelp at eoos.dds.nl> wrote: > >It is not completely clear to me how time zones work with POSIXlt objects. For POSIXct, I can understand what happens: time is always stored in GMT, the `tzone` attribute only affects how the times are displayed. All computations etc. are done in GMT. > >POSIXlt objects have both a `tzone` attribute and a `zone` field. It seems that the `zone` field is largely ignored. It only seems to be used for displaying the times, but does not seem to play a ro...

Thank you for the report. In R-devel, all.equal.POSIXt() by default reports inconsistent time zones. Previously, > x <- Sys.time() > all.equal(x, as.POSIXlt(x, tz = "EST5EDT")) would return TRUE. To ignore the time zone attributes in R-devel, the argument 'check.tzone = FALSE' needs to be used. That said, I can reproduce the 'make check' failure in R-devel on Ubuntu Linux when TZ is set, even if it is set to the system time zone: $ export TZ=Europe/Berlin $ make check [...] > running code in '../../tests/reg-tests-2.R' ... OK > comp...

...of 7 hours Above, t1 and t2 represent the same time in the same specified timezone. Therefore, it is reasonable if their difference is zero. The result is like above because the function '-.POSIXt' calls the function 'difftime', and function 'difftime' does not honor 'tzone' attribute, as can be seen from this part of the function definition. function (time1, time2, tz = "", units = c("auto", "secs", "mins", "hours", "days", "weeks")) { time1 <- as.POSIXct(time1, tz = tz) time2 &...

Hi all; I've already send a similar e-mail to the list and Prof. Brian Ripley answered me but my doubts remain unresolved. Thanks for the clarification, but perhaps I wasn't clear enough in posting my questions. I've got a postgres database which I read into R. The first column is Timestamp with timezone, and my data are already in UTC format. An 'printed' extract of R

It is not completely clear to me how time zones work with POSIXlt objects. For POSIXct, I can understand what happens: time is always stored in GMT, the `tzone` attribute only affects how the times are displayed. All computations etc. are done in GMT. POSIXlt objects have both a `tzone` attribute and a `zone` field. It seems that the `zone` field is largely ignored. It only seems to be used for displaying the times, but does not seem to play a role wh...

...OSIXt() by default >> reports inconsistent time zones. Previously, >> >> > x <- Sys.time() >> > all.equal(x, as.POSIXlt(x, tz = "EST5EDT")) >> >> would return TRUE. To ignore the time zone attributes in R-devel, the >> argument 'check.tzone = FALSE' needs to be used. >> >> That said, I can reproduce the 'make check' failure in R-devel on Ubuntu >> Linux when TZ is set, even if it is set to the system time zone: >> >> $ export TZ=Europe/Berlin >> $ make check >> [...] >> >...

...) { x <- datetime[row,] x1=x[1:length(x)-1] x2=x[2:length(x)] xd=difftime(x2,x1) print (x) print (xd) } [1] "2012-03-31 21:00:00" "2012-04-01 00:00:00" "2012-04-01 03:00:00" "2012-04-01 06:00:00" Time differences in hours [1] 3 4 3 attr(,"tzone") [1] "" [1] "2012-10-06 21:00:00" "2012-10-07 00:00:00" "2012-10-07 03:00:00" "2012-10-07 06:00:00" Time differences in hours [1] 3 2 3 attr(,"tzone") [1] "" Accurate results would be 3 3 3 (hours) in both cases. The probl...

...ng the original order). Jan > On October 10, 2024 6:46:19 AM PDT, Jan van der Laan <rhelp at eoos.dds.nl> wrote: >> >> It is not completely clear to me how time zones work with POSIXlt objects. For POSIXct, I can understand what happens: time is always stored in GMT, the `tzone` attribute only affects how the times are displayed. All computations etc. are done in GMT. >> >> POSIXlt objects have both a `tzone` attribute and a `zone` field. It seems that the `zone` field is largely ignored. It only seems to be used for displaying the times, but does not seem to...

...quot; [2,] "2016-12-06 21:45:42" "2016-12-06 20:45:42" The reason for that, is that dlt has a timezone set, but dct doesn't. To be correct, it only takes the first value "", which indicates "Use the default timezone of the locale". > attr(dlt, "tzone") [1] "" "CET" "CEST" > attr(dct, "tzone") [1] "" The thing is, in POSIXlt the timezone attribute is stored together with the actual values for hour, minute etc. in list format. Changing the timezone doesn't change those values, bu...