similar to: daylight saving / time zone issues with as.POSIXlt/as.POSIXct (PR#10393)

Running under Windows XP 64 bit, as.POSIXlt()/as.POSIXct() seem to think that US time zones (EST5EDT, MST7MDT) switched from daylight savings back to standard time on Oct 28, 2007, whereas the switch is actually on Sun Nov 04, 2007. Examples: > Sys.timezone() [1] "Mountain Daylight Time" > as.POSIXct("2007-10-30 12:38:47") [1] "2007-10-30 12:38:47 Mountain

I'm having difficulties with daylight saving times in US time zones. (Apologies for the long post, but the problem seems subtle and complex, unless I'm doing something completely wrong, in which case it should be evident from the first 10 lines below.) This is what I see, using a (slightly modified) example from ?as.POSIXlt : > as.POSIXlt((d <- Sys.time()), "EST5EDT") #

Hello, I just built openssh 3.8p1 on an HP-UX 11i machine. All looks well except for the timezone. I'm noticing now that when it logs stuff to syslog, it's off by 2 hours for me. What I've figured is this: My timezone is MST7MDT (mountain time). The timezone in /etc/default/tz is EST5EDT (eastern time). There's a 2 hour difference between mountain & eastern time. What

Apologies for the intrusion. I am a lurker on list. I have been working to convert a digitized signal from a matlab file into R for analysis and other applications. R.matlab is working fine, and it is easy to convert the matlab date-time number (days since year 0) into R date-time numbers (seconds since 1970-01-01). Unfortunately, when I cast the R date-time number into POSIXct format it seems

I have a data frame that contains dates, but when I use as.POSIXlt() I lose the hours on all records. I traced this down to a particuar hour which causes the issue... > as.POSIXlt('2004-10-31 02:00:00') [1] "2004-10-31" > as.POSIXlt('2004-10-31 03:00:00') [1] "2004-10-31 03:00:00" How do I tell as.POSIXlt() to ignore daylight savings and just convert to

Tracking down this bug was joint work with Jermoe Asselin (jerome at hivnet.ubc.ca) and Patrick Connolly (p.connolly at hortresearch.co.nz). We collectively were able to determine that this is a problem in both Windows 2000 and in Linux and by testing it in our three time zones that it seems to be daylight savings time related. Conversion of POSIXlt datetimes to POSIXct appears to have problems.

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"))

Full_Name: Erich Neuwirth Version: 2.3.1 OS: Windows XP, Linux Submission from: (NULL) (131.130.135.167) Converting Sys.Date() to a POSIX compliant time type in different ways produces inconsistent results: > Sys.date() [1] "2006-09-01" > as.POSIXct(Sys.Date()) [1] "2006-09-01 02:00:00 CEST" > as.POSIXlt(Sys.Date()) [1] "2006-09-01" >

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

R-devel: Some very inconsistent behavior, that I can't seem to find documented. Sys.setenv(TZ="GMT") str(unclass(strptime("1969-12-31 23:59:59","%Y-%m-%d %H:%M:%S"))) List of 9 $ sec : num 59 $ min : int 59 $ hour : int 23 $ mday : int 31 $ mon : int 11 $ year : int 69 $ wday : int 3 $ yday : int 364 $ isdst: int 0 - attr(*, "tzone")= chr

rug() may add integer axis labels when called with a POSIXlt object as argument. dtimes <- c("09/29/2007 12:54", "09/30/2007 00:14", "10/01/2007 00:14", "10/02/2007 00:14", "10/03/2007 00:14", "10/04/2007 00:14", "10/05/2007 00:14", "10/06/2007 00:14", "10/07/2007

I have found what looks like a small 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 following code: cut(as.POSIXct("2009-11-01 04:00:00", tz="America/Los_Angeles"), "1 day") gives the error: Error in seq.int(0, to - from, by) : 'to' must be finite This is related to November 1st, 2009 being the switchover date from daylight savings time to standard time in the America/Los_Angeles time zone. In particular, in cut.POSIXt, the starting

?Hi again, I take advantage of my previous mail to ask you a question for which I was looking for an answer when detected the behaviour I previously told. In the help of DataTimeClasses one can read: "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

Hi. This feels like a bug to me, or at least an undocumented feature, but I thought I'd see what people here thought of it. Consider a POSIXlt object like this one: > a <- as.POSIXlt ("2011-01-23 12:45:45") > class (a) [1] "POSIXlt" "POSIXt" Fine. Now, if I do some arithmetic on that object, the result is converted to POSIXct. > class (a

Colleagues, I submitted this several days ago and no one responded, so I am trying again, trying a different subject line: I just encountered some unexpected behavior of difftime in relationship to the change from daylight savings to standard time. My understanding is that DST and ST take effect at 2AM. However, the results below suggests that R (version 2.8.0 in OS X) implements the

I have asked this question before, and received some suggestions for work-arounds that get the job done--and they are much appreciated. But I would still like to find out if I'm missing something, and whether there is a direct way using POSIXt functions (as.POSIXct, as.POSIXlt, strptime, in particular). I have environmental data collected once per minute. Here is a subset of 3 input

This is not a bug in R: the documentation does say the result is OS-specific. `GMT' is a not a proper timezone on Windows, so NA is a valid answer. (Windows seems to use GMT to refer to the timezone of the UK, e.g. > Sys.time() [1] "2005-07-11 07:49:56 GMT Daylight Time" > Sys.timezone() [1] "GMT Daylight Time" although I am in British Summer Time not GMT.)

Under R-2.2.1, a POSIXlt date created with "strptime" has an unknown Daylight Savings Time flag: > strptime(20051208, "%Y%m%d")$isdst [1] -1 This is true on both Linux (details below) and Windows. It did not occur under R-2.1.0. Any ideas? TIA! > Sys.getenv("TZ") TZ "" Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu

There is incompatibility between R strptime and musl libc. I posted about it on their mailing list, but they need more information I can't provide, so I'm forwarding the message here in hope R developers can help. Thanks. ---------- Forwarded message ---------- From: Rich Felker <dalias at libc.org> Date: Thu, Feb 4, 2016 at 2:07 PM Subject: Re: [musl] strptime() question To: Alba