similar to: Conversion and rounding of 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

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.

Thank you, Jskud. I can reproduce your problem, though not the seg.fault, see below >>>>> "Jskud" == Jskud <Jskud@Jskud.com> >>>>> on Sat, 30 Apr 2005 09:04:03 +0200 (CEST) writes: Jskud> In attempting to build R using rpmbuild --rebuild Jskud> R-2.1.0-0.fdr.2.fc3.src.rpm Jskud> on a fairly up-to-date RedHat 9 system (that

Dear Peter, Thank you very much for your kind and helpful reply. As I mentioned in a followup email to r-bugs, indeed, one aspect of this issue is a (user specified) shorter stack than that expected by R -- I had only allowed 1 MB of stack space a long long time ago, and forgotten about it. Due to a glitch with r-bugs@r-project.org, I ended up submitting this bug twice, and your original

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

In trying to use as.Date(), I've come across the conversion of POSIXlt to POSIXct when a POSIXlt variable is included in a data frame: my_POSIX <- strptime(c("11-09-2006", "11-10-2006", "11-11-2006", "11-12-2006", "11-13-2006"), "%m-%d-%Y") str(my_POSIX) my_Date <- as.Date(my_POSIX) str(my_Date) data <- format(my_Date)

R 2.6.1 on a Thinkpad T60 running up-to-date Gentoo: Despite the documentation, which says: 'strftime' is an alias for 'format.POSIXlt', and 'format.POSIXct' first converts to class '"POSIXlt"' by calling 'as.POSIXlt'. Note that only that conversion depends on the time zone. strftime fails on POSIXct objects: > foo <-

In attempting to build R using rpmbuild --rebuild R-2.1.0-0.fdr.2.fc3.src.rpm on a fairly up-to-date RedHat 9 system (that is, with patches installed through May 1 2004), it failed at the make check-all step. The problem was reproducible by going into the tests directory and make test-Segfault The last lines of the saved file no-segfault.Rout.fail are > > ## c.POSIXct : > >

In attempting to build R using rpmbuild --rebuild R-2.1.0-0.fdr.2.fc3.src.rpm on a fairly up-to-date RedHat 9 system (that is, with patches installed through May 1 2004), it failed at the make check-all step. The problem was reproducible by going into the tests directory and make test-Segfault The last lines of the saved file no-segfault.Rout.fail are > > ## c.POSIXct : > >

Hi, I am trying to define the as.POSIXct as an S4 method for one of my classes. Trying to define a generic, I am getting an error that it is already differently defined in base. However, if I query for it, there is no definition. Being in base, I also cannot really import it. If I define methods without definig a generic, they will work but with a warning that a new generic will be automatically

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.

Hello folks, I found a strangeness while experimenting with POSIXct vectors and lists. It seems that coerced NA's aren't "real" NAs, at least as considered by is.na()? > date_vec = c(as.POSIXct(now()), as.POSIXct(now()+1),NA,"b") > date_vec [1] "2012-08-22 15:00:46 COT" "2012-08-22 15:00:47 COT" NA [4] NA Warning message: In

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

Although the documentation is somewhat sketchy, I() can be used to create objects of class AsIs: > I("a") [1] "a" attr(,"class") [1] "AsIs" "character" > I(4) [1] 4 attr(,"class") [1] "AsIs" "numeric" > I(4 + 0i) [1] 4+0i attr(,"class") [1] "AsIs" "complex" > This

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

>>>>> Tim Taylor >>>>> on Thu, 6 Jul 2023 15:11:41 +0100 writes: > Ah yes ... and reading the as.data.frame help we see (emphasis mine): > "... Direct calls to as.data.frame.<class>() are still possible (*base > package!*), for 12 atomic base classes, but will deprecated ..." > So it does seem that a lot of these

In an optimized build, debug info is just an approximation. It might help to debug in a build of R and packages without compiler optimizations (-O0), where the debug information is accurate. However, first I would try to modify the example to trigger more often, or try to find external ways to make it trigger more often (e.g. via gctorture). Then I would try to make the example smaller (not

Dear R-helpers, I have a problem converting an object made with the 'chron' function to a POSIXct object: # Make date based on DOY dat <- chron(dates=232, origin.=c(month=1, day=1, year=2008)) dat #[1] 08/20/08 # Converting to POSIXct uses current timezone (Sydney): as.POSIXct(dat) #[1] "2008-08-20 10:00:00 EST" # Setting GMT timezone has no effect? as.POSIXct(dat,

Hey R folks, i found some strange (to me) behaviour with chron to POSIXct conversion. The two lines of code result in two different results, on ewith the correct time zone, one without: library(chron) as.POSIXct(chron('12/12/2000'), tz = 'UTC') as.POSIXlt(chron('12/12/2000'), tz = 'UTC') Only the code below would give me a POSIXct object with the correct time