search for: isdst

Can someone, please, explain the difference is results below (notice the isdst value) > unlist(as.POSIXlt('2005-7-1')) sec min hour mday mon year wday yday isdst 0 0 0 1 6 105 5 181 1 > unlist(as.POSIXlt(as.Date('2005-7-1'))) sec min hour mday mon year wday yday isdst 0 0 0 1 6...

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

...;2016-03-23 CDT" # On Linux (tested on Ubuntu 14.04) -- not as expected as.POSIXct(as.POSIXlt(dates), tz = "America/Chicago") # [1] "2016-03-02 00:00:00 CST" "2016-03-09 00:00:00 CST" "2016-03-16 01:00:00 CDT" "2016-03-23 01:00:00 CDT" # 'isdst' attribute is identical on OS X / Windows / Ubuntu, as expected # since dates don't have timezones, as pointed out by @JoshuaUlrich under # issue #1619. lt = as.POSIXlt(dates) lt$isdst # [1] 0 0 0 0 # However, as Dirk points out, setting isdst to -1 on Ubuntu returns expected results lt$is...

...llowing where lt1 and lt2 are both POSIXlt dates that correspond to the same date even though they were created using different statements. Even though lt1 and lt2 represent the same date, as.POSIXct(lt1,tz="") and as.POSIXct(lt2,tz="") differ by one hour. One clue is that the isdst flag is set in lt1 but not in lt2. However, both lt1 and lt2 are GMT dates and either the isdst flag should not be set or at least subsequent processing should not depend on it. Furthermore, even though lt1 is the one that has isdst set I am not entirely sure whether its that one or the other one...

> 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

...t;2010-02-05 20:00:01.43" [[2]] [1] "2010-02-05 20:00:02.274" [[3]] [1] "2010-02-05 20:00:02.274" [[4]] [1] "2010-02-05 20:00:06.34" However, when I do an unlist...I gets converted to something like this... sec min hour mday mon year wday yday isdst sec min hour mday mon year wday yday isdst sec 1.430 0.000 20.000 5.000 1.000 110.000 5.000 35.000 0.000 2.274 0.000 20.000 5.000 1.000 110.000 5.000 35.000 0.000 2.274 min hour mday mon year wday yday isdst sec min hou...

...ich aren't consistent with the OS? Example: Expected result: in New Zealand DST stopped (NZDT -> NZST) at 03:00 NZDT on 2010-04-04, as confirmed by the OS time zone info (OS X 10.8.2): zdump -v /etc/localtime /etc/localtime Sat Apr 3 13:59:59 2010 UTC = Sun Apr 4 02:59:59 2010 NZDT isdst=1 /etc/localtime Sat Apr 3 14:00:00 2010 UTC = Sun Apr 4 02:00:00 2010 NZST isdst=0 Result in R: R has DST changing at 02:26:08, instead of 03:00! > a<-as.POSIXlt('2010-04-04 02:26:07',tz="NZ") > a$isdst [1] 1 > b<-as.POSIXlt('2010-04-04 02:26:08'...

...]) is not the solution.... begin=paste(dates[i]-1,"09:00:00") end=paste(dates[i],"08:00:00") acc.period=seq(as.POSIXct(begin),as.POSIXct(end),"hour") unlist(strptime(acc.period[16],format="%Y-%m-%d %H:%M:%S")) # sec min hour mday mon year wday yday isdst # NA NA NA NA NA NA NA NA -1 unlist(strptime(acc.period[17],format="%Y-%m-%d %H:%M:%S")) # sec min hour mday mon year wday yday isdst # 0 0 1 1 2 106 3 59 0 a="2006-03-01 00:00:00" unlist(strptime(a,format=&q...

...eturn ? 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 >...

...DT" | | # On Linux (tested on Ubuntu 14.04) -- not as expected | as.POSIXct(as.POSIXlt(dates), tz = "America/Chicago") | # [1] "2016-03-02 00:00:00 CST" "2016-03-09 00:00:00 CST" "2016-03-16 | 01:00:00 CDT" "2016-03-23 01:00:00 CDT" | | # 'isdst' attribute is identical on OS X / Windows / Ubuntu, as expected | # since dates don't have timezones, as pointed out by @JoshuaUlrich under | # issue #1619. | lt = as.POSIXlt(dates) | lt$isdst | # [1] 0 0 0 0 | | # However, as Dirk points out, setting isdst to -1 on Ubuntu returns | expect...

...================= The data generated and the plots look fine. R issues a warning on the round() function when rtime is set, though. It looks like this: > round(range(cgmtime), "hours") [1] "2003-11-04 14:00:00 EST" "2003-11-07 11:00:00 EST" Warning message: In if (isdst == -1) { : the condition has length > 1 and only the first element will be used > Am I approaching this incorrectly? Is there another way to achieve the same result without the warning? Or is there a way I can suppress the warning? Thanks in advance, Clay

...all problem in trunc.POSIXt() involving the transition to/from standard time and daylight savings time. Assuming my assessment is correct, I have a potential solution to offer. If a time in daylight savings time is rounded such that the rounded value is on the other side of the transition, the isdst element does not get changed accordingly. I have tested only the case of PDT rounded to PST in the US/Pacific time zone. I have tested it on (only) two different platforms, with slightly different results. See below. More specifically, in the US/Pacific time zone the transition from standard...

...13L, 13L, 13L, 13L, NA, 13L, 13L, 13L), mon = c(5L, 5L, 5L, 5L, 5L, 5L, 5L, NA, 5L, 5L, 5L), year = c(105L, 105L, 105L, 105L, 105L, 105L, 105L, NA, 105L, 105L, 105L), wday = c(1L, 1L, 1L, 1L, 1L, 1L, 1L, NA, 1L, 1L, 1L), yday = c(163L, 163L, 163L, 163L, 163L, 163L, 163L, NA, 163L, 163L, 163L), isdst = c(1L, 1L, 1L, 1L, 1L, 1L, 1L, -1L, 1L, 1L, 1L)), .Names = c("sec", "min", "hour", "mday", "mon", "year", "wday", "yday", "isdst" ), class = c("POSIXt", "POSIXlt")) print(tv) # print 11...

...ot;zdump -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 = N...

...10L, 110L, 110L, 110L, 110L, 110L, 110L, 110L, 110L, 110L, 110L), wday = c(1L, 2L, 3L, 4L, 5L, 1L, 2L, 3L, 4L, 5L, 1L, 2L, 3L, 4L, 5L, 1L, 2L, 3L, 4L, 5L, 1L), yday = c(304L, 305L, 306L, 307L, 308L, 311L, 312L, 313L, 314L, 315L, 318L, 319L, 320L, 321L, 322L, 325L, 326L, 327L, 328L, 329L, 332L), isdst = c(0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L)), .Names = c("sec", "min", "hour", "mday", "mon", "year", "wday", "yday", "isdst"), class = c("POSIXt", &quo...

Hello, Suppose we need a function that takes a POSIXct object and need to calculate the time difference between it and GMT time: gmtDiff <- function(time) { time.gmt <- as.POSIXct(format(time, tz="GMT")) time.plt <- as.POSIXlt(time) dlstime <- ifelse(time.plt$isdst > 0, 1, 0) timezone <- as.numeric(difftime(time, time.gmt, units="hours")) timezone - dlstime } Please note this assumes no daylight savings if the 'isdst' component for the POSIXlt object is negative (i.e. don't know if DST is in effect). Now if we pass some...

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:

Have you noticed any problems with big dates (>=1/1/2040) in R? Here is the bit of code that I'm having trouble with: > test.date <- strptime("1/1/2040",format="%m/%d/%Y") > > unlist(test.date) sec min hour mday mon year wday yday isdst 0 0 0 1 0 140 0 0 0 > > date.plus.one <- as.POSIXct(test.date) + 24*60*60 > date.plus.one.lt <- as.POSIXlt(date.plus.one) > > unlist(date.plus.one.lt) sec min hour mday mon year wday yday isdst 0 0 0 2 0 14...

...with a non GMT zone (also non specifying tz if the Sys.timezone is not GMT) gets a character vector due to including the `zone` element. > x <- as.POSIXlt(Sys.time(), "GMT") > (y <- unlist(x)) sec min hour mday mon year wday yday isdst 54.99715 26.00000 16.00000 23.00000 9.00000 120.00000 5.00000 296.00000 0.00000 > str(y) Named num [1:9] 55 26 16 23 9 ... - attr(*, "names")= chr [1:9] "sec" "min" "hour" "mday" ... > x <- as.POSIXlt(Sys.time(), "CET&quot...

A quick fix for anyone running into this problem: load_schedule was crashing cron_trigger.rb#160, and I found that for triggers like "0 20 5 * * * *" it was putting in 32 for the date (even though its Mon Mar 31 04:16:21 BST 2008). Something to do with switching to day light savings I think, which concludes after 2am. I patched it by adding day = 31 if day == 32 on the line before.