similar to: (PR#7826) Re: ... print.POSIXct .. infinite recursion

Displaying 20 results from an estimated 8000 matches similar to: "(PR#7826) Re: ... print.POSIXct .. infinite recursion"

2005 May 01
0
Re: (PR#7826) ... segfault during build of 2.1.0 on RH9; print.POSIXct ...
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
2005 Apr 30
2
(PR#7826) segfault during build of 2.1.0 on RH9; print.POSIXct
1) Why did you submit this *twice*, as PR#7826 and PR#7827? Please don't be so careless of the volunteers' time. 2) > print.POSIXct function (x, ...) { print(format(x, usetz = TRUE, ...), ...) invisible(x) } is definitely *not* implicated. (Use of ... in two places is correct.) 3) On FC3: > unusual_and_faults Error: protect(): protection stack overflow >
2005 Apr 30
1
segfault during build of 2.1.0 on RH9; print.POSIXct implicated (PR#7827)
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 : > >
2005 Apr 30
0
segfault during build of 2.1.0 on RH9; print.POSIXct implicated (PR#7826)
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 : > >
2008 Feb 04
1
strftime fails on POSIXct objects (PR#10695)
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 <-
2016 Dec 16
0
print.POSIXct doesn't seem to use tz argument, as per its example
>>>>> Jennifer Lyon <jennifer.s.lyon at gmail.com> >>>>> on Thu, 15 Dec 2016 09:33:30 -0700 writes: > On the documentation page for DateTimeClasses, in the Examples section, > there are the following two lines: > > format(.leap.seconds) # the leap seconds in your time zone > print(.leap.seconds, tz = "PST8PDT") # and in
2019 Aug 02
0
Infrequent but steady NULL-pointer caused segfault in as.POSIXlt.POSIXct (R 3.4.4)
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
2019 Aug 04
1
Infrequent but steady NULL-pointer caused segfault in as.POSIXlt.POSIXct (R 3.4.4)
A reply from stackoverflow suggests I might have hit this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14023 I can confirm that this glibc bug affects my system (latest CentOS 7). However, as far as I know, R is not multithreaded in its core. Is it possible that some library triggered this? Regards, Steve Tomas Kalibera <tomas.kalibera at gmail.com> ?2019?8?2??? ??4:59??? >
2007 Feb 16
0
Request: make as.POSIXlt generic
In the base package, as.POSIXct() is an S3 generic function, but as.POSIXlt() is not. As shown below, the current implementation is already crying out to be refactored into a generic function with methods for various classes. It calls "inherits" five times. Not only is this bad style, it also disallows me or anyone else from making as.POSIXlt() work with other kinds of time-ish
2016 Dec 15
2
print.POSIXct doesn't seem to use tz argument, as per its example
On the documentation page for DateTimeClasses, in the Examples section, there are the following two lines: format(.leap.seconds) # the leap seconds in your time zone print(.leap.seconds, tz = "PST8PDT") # and in Seattle's The second line (using print) seems to ignore the tz argument, and prints the dates in my time zone, while: format(.leap.seconds, tz =
2019 Aug 02
4
Infrequent but steady NULL-pointer caused segfault in as.POSIXlt.POSIXct (R 3.4.4)
The R script I run daily for hours looks like this: while (!finish) { Sys.sleep(0.1) time = as.integer(format(Sys.time(), "%H%M")) # always crash here if (new.data.timestamp() <= time) next # ... do some jobs for about 2 minutes ... gc() } Basically it waits for new data, which comes in every 10 minutes, and do some jobs, then gc(), then loop again. It
2006 Sep 25
0
na.encode in format for Date and POSIXt classes
Hello! na.encode does not have any effect on format of NA values of Date and POSIXct (POSIXlt?) "atomic" classes in a data.frame. Here is the example (the same in R 2.3.1 and 2.5.0 (2006-09-19 r39409)): testData <- data.frame(num=c(NA, 2.6), int=c(1, NA), fac=factor(c(NA, "abc")), cha=c("a",
2003 Aug 04
0
as.POSIXct Bug when used with POSIXlt arg and tz= arg (PR#3646)
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.
2001 May 15
1
what happende to as.POSIC.ct ???
In my 1021-version I get: > version _ platform i386-pc-mingw32 arch x86 os Win32 system x86, Win32 status major 1 minor 2.1 year 2001 month 01 day 15 language R > as.POSIXct( "1970/01/01" ) [1]
2009 Mar 15
1
Conversion and rounding of POSIXct
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 >
2012 Dec 13
1
duplicated.data.frame() and POSIXct with DST shift
Hi, I encountered the behavior, that the duplicated method for data.frames gives "false positives" if there are columns of class POSIXct with a clock shift from DST to standard time. time <- as.POSIXct("2012-10-28 02:00", tz="Europe/Vienna") + c(0, 60*60) time [1] "2012-10-28 02:00:00 CEST" "2012-10-28 02:00:00 CET" df <-
2009 Feb 27
0
POSIXlt, POSIXct, strptime, GMT and 1969-12-31 23:59:59
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
2006 Nov 09
1
POSIXlt converted to POSIXct in as.data.frame()
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)
2008 Mar 26
0
as.POSIXct/as.POSIXlt generics
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
2007 Nov 01
0
daylight saving / time zone issues with as.POSIXlt/as.POSIXct (PR#10393)
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).