search for: gmtoff

I've been searching for patterns in why some POSIXlt objects have the zone and gmtoff components and some don't and why gmtoff is sometimes NA when the zone is known. Is there a pattern or is it just that the additional fields and workarounds were added in an ad hoc way? E.g., as.POSIXlt adds the zone and gmtoff components for all strings and logical NA inputs if the time zon...

I read a few days back on the list where the tzdata rpm was to take care of the new DST rules. I run CentOS 3 servers, and did a 'yum update tzdata' , but received a 2006a update of the rpm. Is this proper? It sure didn't fix anything. Thanks Steve Campbell campbell at cnpapers.com Charleston Newspapers

> Date: Tuesday, June 23, 2015 03:48:36 PM -0400 > From: Jonathan Billings <billings at negate.org> > > On Tue, Jun 23, 2015 at 01:56:13PM -0500, g wrote: >> each and every time i run yum or yumex, system time is advanced >> by 5 hours. >> >> this has gone on thru several updates, maybe even upgrades. >> >> centos = 6.6 current >> yum

...i.e., is it for >> the correct TZ? > > [geo at boxen ~]$ zdump -v /etc/localtime > /etc/localtime -9223372036854775808 = NULL > /etc/localtime -9223372036854689408 = NULL > /etc/localtime Sun Nov 18 17:59:59 1883 UTC = Sun Nov 18 12:09:23 > 1883 LMT isdst=0 gmtoff=-21036 > > <one hell of a long list snipped> > > /etc/localtime Sun Nov 1 06:59:59 2499 UTC = Sun Nov 1 01:59:59 > 2499 CDT isdst=1 gmtoff=-18000 > /etc/localtime Sun Nov 1 07:00:00 2499 UTC = Sun Nov 1 01:00:00 > 2499 CST isdst=0 gmtoff=-21600 > /etc/loc...

...-v /etc/localtime" return ? i.e., is it for > the correct TZ? [geo at boxen ~]$ zdump -v /etc/localtime /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime Sun Nov 18 17:59:59 1883 UTC = Sun Nov 18 12:09:23 1883 LMT isdst=0 gmtoff=-21036 <one hell of a long list snipped> /etc/localtime Sun Nov 1 06:59:59 2499 UTC = Sun Nov 1 01:59:59 2499 CDT isdst=1 gmtoff=-18000 /etc/localtime Sun Nov 1 07:00:00 2499 UTC = Sun Nov 1 01:00:00 2499 CST isdst=0 gmtoff=-21600 /etc/localtime 9223372036854689407 = NULL /et...

Hi, I'm using gotoiftime on asterisk, but it seems&nbsp; there is a difference between the asterisk time and the system time. could it be because i adjusted the system timezone on my linux? do asterisk not detect the change of timezone on the system? How can I fix this prob? Regards, nhadie -------------- next part -------------- An HTML attachment was scrubbed... URL:

...tes(x) $class [1] "POSIXct" "POSIXt" > attributes(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...

...ially) times in different time zones. Using POXIXlt objects seems like they could store/support this. But working with this seems unpractical as the `zone` field does not seem to do anything: t1$zone <- c("CET", "GMT") t1 - t2 #Time differences in secs #[1] 0 0 Also the `gmtoff` field does not seem to do anything. For what/where is this field used? t1$gmtoff <- c(3600, 0) t1 #[1] "2024-01-01 12:30:00 CET" "2024-01-01 12:30:00 GMT" t1 - t2 #Time differences in secs #[1] 0 0 as.POSIXct(t1) #[1] "2024-01-01 12:30:00 CET" "2024-01-01...

...time zones. Using POXIXlt objects seems like they could store/support this. But working with this seems unpractical as the `zone` field does not seem to do anything: > >t1$zone <- c("CET", "GMT") >t1 - t2 >#Time differences in secs >#[1] 0 0 > >Also the `gmtoff` field does not seem to do anything. For what/where is this field used? > >t1$gmtoff <- c(3600, 0) >t1 >#[1] "2024-01-01 12:30:00 CET" "2024-01-01 12:30:00 GMT" > >t1 - t2 >#Time differences in secs >#[1] 0 0 > >as.POSIXct(t1) >#[1] "2024...

Sorry for the extra info required, but I had digest mode turned on and wouldn't have received the mailing till tomorrow. I have since updated the data manually, but after 'yum update tzdata' was run, the zdump -v for EST5EDT and America/New_York all still showed a date of April 1, instead of March 11. After manually fixing, it is correct. This was mostly a question about why yum

...rt this. But working with this seems unpractical as the `zone` field does not seem to do anything: > >> > >> t1$zone <- c("CET", "GMT") > >> t1 - t2 > >> #Time differences in secs > >> #[1] 0 0 > >> > >> Also the `gmtoff` field does not seem to do anything. For what/where is this field used? > >> > >> t1$gmtoff <- c(3600, 0) > >> t1 > >> #[1] "2024-01-01 12:30:00 CET" "2024-01-01 12:30:00 GMT" > >> > >> t1 - t2 > >> #Time differen...

...6")) > d$zone <- "CET" # = previous, but 'zone' now is last > tools::assertError(format(d)) > dlt <- structure( + list(sec = 52, min = 59L, hour = 18L, mday = 6L, mon = 11L, year = 116L, + wday = 2L, yday = 340L, isdst = 0L, zone = "CET", gmtoff = 3600L), + class = c("POSIXlt", "POSIXt"), tzone = c("", "CET", "CEST")) > dlt$sec <- 10000 + 1:10 # almost three hours & uses re-cycling .. > fd <- format(dlt) > stopifnot(length(fd) == 10, identical(fd, format(dct <- as....

...6")) > d$zone <- "CET" # = previous, but 'zone' now is last > tools::assertError(format(d)) > dlt <- structure( + list(sec = 52, min = 59L, hour = 18L, mday = 6L, mon = 11L, year = 116L, + wday = 2L, yday = 340L, isdst = 0L, zone = "CET", gmtoff = 3600L), + class = c("POSIXlt", "POSIXt"), tzone = c("", "CET", "CEST")) > dlt$sec <- 10000 + 1:10 # almost three hours & uses re-cycling .. > fd <- format(dlt) > stopifnot(length(fd) == 10, identical(fd, format(dct <- as....

...s seems like they could store/support this. But working with this seems unpractical as the `zone` field does not seem to do anything: >> >> t1$zone <- c("CET", "GMT") >> t1 - t2 >> #Time differences in secs >> #[1] 0 0 >> >> Also the `gmtoff` field does not seem to do anything. For what/where is this field used? >> >> t1$gmtoff <- c(3600, 0) >> t1 >> #[1] "2024-01-01 12:30:00 CET" "2024-01-01 12:30:00 GMT" >> >> t1 - t2 >> #Time differences in secs >> #[1] 0 0 >&...

...yday "19.5111262798309" "27" "18" "23" "9" "120" "5" "296" isdst zone gmtoff "1" "CEST" "7200" > str(y) Named chr [1:11] "19.5111262798309" "27" "18" "23" "9" "120" "5" "296" "1" "CEST" "7200"...

...uot; > > > >> attributes(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 developm...

...t I don't know if these questions are not already obvious, but: 1. Is there a reasonable way to fail more elegantly when a user makes this mistake? 2. Should we update the documentation for POSIXlt to warn people that the optional "zone" list element must precede the optional "gmtoff" list element, in cases where both are present? Thanks, Frederick

...ior to \R 4.3.0. All objects created in \R 4.3.0 have the optional - components. From earlier versions of \R, he last two components will + components. From earlier versions of \R, the last two components will not be present for times in UTC and are platform-dependent. Currently \code{gmtoff} is set on almost all current platforms: those based on BSD or \code{glibc} (including Linux and macOS) and those using the Hope this helps, Rui Barradas -- Este e-mail foi analisado pelo software antiv?rus AVG para verificar a presen?a de v?rus. www.avg.com

...s seems like they could store/support this. But working with this seems unpractical as the `zone` field does not seem to do anything: >> >> t1$zone <- c("CET", "GMT") >> t1 - t2 >> #Time differences in secs >> #[1] 0 0 >> >> Also the `gmtoff` field does not seem to do anything. For what/where is this field used? >> >> t1$gmtoff <- c(3600, 0) >> t1 >> #[1] "2024-01-01 12:30:00 CET" "2024-01-01 12:30:00 GMT" >> >> t1 - t2 >> #Time differences in secs >> #[1] 0 0 >&...

...POSIXct" "POSIXt" > >> attributes(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...