similar to: POSIXct time zone and daylight savings issues

I realize it's -12C and we're having the next best thing to a blizzard but why can I not melt this data frame. I am missing something terribly obvious but I just don't understand what the error message is saying. John Kane Kingston ON Canada Code and aata below #================================================# library(reshape2) melt(mydata, id.vars = c("date"))

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

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

Hello, Following Dirk's post here: https://github.com/Rdatatable/data.table/issues/1619 we would like to clarify if this is the right behaviour, and if so, the rationale behind it. Here's the summary (thanks to Dirk and Joshua): Sys.setenv("TZ"="America/Chicago") dates = as.Date("2016-03-02") + (0:3)*7 # four Wednesdays # [1] "2016-03-02"

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

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

Hi, I'm getting a segmentation fault as follows: ---<--------------------cut here---------------start------------------->--- R> begt <- as.POSIXct(strptime("10/01/2009 06:00:00", format="%d/%m/%Y %H:%M:%S"), + tz="GMT") R> tser <- seq(begt, by=5, length.out=91000) R> tser.trunc <- format(tser) Error: segfault from C

Hi, Using the following simple character vector representing a time series with fractional seconds: datetime <- c("20/09/2011 13:00:59.00", "20/09/2011 13:00:59.02", "20/09/2011 13:00:59.04") Conversion to POSIXct runs into problems; the second element is not interpreted correctly: ---<--------------------cut

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.

tplate at acm.org wrote: > 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. > > =20 Not Our Problem. (This sort of thing never is. We are wholly dependent=20 on the OS for this information).

Bumping this up to the front again ... because it exhibits a difference in behaviour of R across OSs. Such a 'feature' may not be desirable. On 4 April 2016 at 18:00, Arunkumar Srinivasan wrote: | Hello, | | Following Dirk's post here: https://github.com/Rdatatable/data.table/issues/1619 | we would like to clarify if this is the right behaviour, and if so, | the rationale behind it.

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

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.

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

Dear all, I have just detected what seems a minor inconsistence with data types. If one unlists a POSIXlt time with GMT zone gets a numeric vector, since the POSIXlt list has no `zone` element, while if one unlists a POSIXlt time 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 <-

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

I am finding that axis.POSIXct uses the local timezone for deciding where to put tic marks, even if the data being plotted are in another time zone. The solution is to use attr() to copy from the 'x' (provided as an argument) to the 'z' (used for the 'at' locations). I have pasted my proposed solution in section 1 below (as a diff). Then, in section 2, I'll put some

Hello everyone, I'm having a big trouble with which seems to be a bug in as.POSIXct() date-time conversion. I have massive GPS datasets in which each location has it's own date and time attribute. As I convert them to POSIXct format, 1300 cases (of about half a million locations) simply return NA values. I picked up a small sample of failed cases and normal cases to demonstrate the

Hi, I have a dataframe column of the form v<-c("Fri Feb 05 20:00:01.43000 2010","Fri Feb 05 20:00:02.274000 2010","Fri Feb 05 20:00:02.274000 2010","Fri Feb 05 20:00:06.34000 2010") I need to convert this to datetime form. I did the following.. lapply(v,function(x){strptime(x, "%a %b %d %H:%M:%OS %Y")}) This gives me a list that looks like

Can anyone please shed any light on why R DateTimeClasses give weird times for when daylight saving time information changes, and which 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