similar to: inconsistent results for axis.POSIXct

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

I have encountered the following behaviour in lattice in 2.6.1 (and 2.4.0) which differs depending upon the type you use. I believe the numeric behaviour to be correct, and the POSIXct behaviour to be in error. When the x data and x axis in a lattice graph are POSIXct, and when using scales$x$at and scales$x$labels to add custom labels: If the first visible at value is not the first

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"

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

Dear R list, I noticed the following 'problem' when changing the format of dates created with seq.dates() (from the Chron library) using as.POSIXct() (R 1.8.0 on OSX 10.2.8): > datesTest<-seq.dates(from="10/01/1952", length=3, by="days"); > datesTest [1] 10/01/52 10/02/52 10/03/52 # Now changing the format to show year as 1952. >

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.

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 an example of this problem under R 1.9.1: > x <-

Hi Ben Thanks for your answer I have already tried this, as well as x <- as.POSIXct(strptime("2002-02-02 02:02", "%Y-%m-%d %H:%M")) It works! But it does not fix it widely for all tests used during the "make check" step at compile time. Unless I patch all of them. There is something with localtime but I cannot find what. On another machine with another

Hello, I'm having problems working with date values in POSIXct format. Here is what I got (eg.lig attached): x <- read.table("eg.txt", sep = ',', col.names=c("ok","time","secs","lig")) # it gives time as factor z <- cbind(x,colsplit(x$time, split="\\s", names=c("date", "clock")))

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

I noticed the addition of the Dates class for dates without times, in R 1.9. I am making extensive use of POSIXct at present and would like to know whether it is worth changing to Dates. What are a few of the trade-offs? Thanks, Frank --- Frank E Harrell Jr Professor and Chair School of Medicine Department of Biostatistics Vanderbilt University

I have looked at ?as.POSIXct ?POSIXct and many of the references that are on those pages. I am bewildered with timezones. Is there a way to get what would go into tz="" for making a function that uses POSIXct to be able to be used in all of the timezones in just the united states? This is for both windows and mac... this is the function that I am wanting to use it with

I have some questions and comments on timezones. Problem 1. # get current time in current time zone > (now <- Sys.time()) [1] "2003-07-29 18:23:58 Eastern Daylight Time" # convert this to GMT > (now.gmt <- as.POSIXlt(now,tz="GMT")) [1] "2003-07-29 22:23:58 GMT" # take difference > now-now.gmt Time difference of -5 hours Note that the difference

Full_Name: Mario Luoni Version: 2.10.0 OS: Windows XP HE SP3 Submission from: (NULL) (217.194.59.134) This piece of code: zzz1 <- as.POSIXct("1999-03-18", tz="CET") zzz2 <- as.POSIXlt("1999-03-18", tz="CET") zzz1 == zzz2 as.Date(zzz1) as.Date(zzz2) yields TRUE for "zzz1==zzz2", but the two dates returned by as.Date are different: >

Hi: I do not understand the returned value of NA in the following, which is a simplified version of my attempt to convert the start column of the data frame AirQual in the SwissAir package. as.POSIXct(paste('04.04.2004 0',0:3,sep=''),format='%d.%m.%Y %H') [1] "2004-04-04 00:00:00 EST" "2004-04-04 01:00:00 EST" [3] NA

I think that there is a bug in the as.POSIXct function on Windows. Here is what I get on Win2000, Pentium III machine in R 1.8.1. > dd1 <- ISOdatetime(2003, 10, 26, 0, 59, 59) > dd2 <- ISOdatetime(2003, 10, 26, 1, 0, 0) > dd2 - dd1 Time difference of 1.000278 hours Now, the 26th of October was the day that change to the standard time occurred, so I suspect that this has

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.

POSIXct/lt supports fractional seconds (see Sub-second Accuracy section of man page), but there seem to be some inconsistencies in their handling. Converting to POSIXlt and back does not give back the same time for times before the origin: > t0 <- as.POSIXct('1934-01-05 23:59:59.00001') > t0 [1] "1934-01-06 00:00:00 EST" # rounding issue, see below >

Dear All, what determines if a difference between POSIXct objects gets expressed in days or seconds? In the following example, it's sometimes seconds, sometimes days. as.POSIXct('2009-09-01') - as.POSIXct(NA) Time difference of NA secs c(as.POSIXct('2009-09-01'), as.POSIXct(NA)) - c(as.POSIXct('2009-09-01'), as.POSIXct('2009-08-31')) Time differences in