similar to: R 3.2.4-revised is released

My CRAN mirror still says this: The latest release (Thursday 2016-03-10, Very Secure Dishes) R-3.2.4.tar.gz, read what's new in the latest version. Should that not be updated? Anyone who has not seen that post won't know to look further. On Wed, 16-Mar-2016 at 08:39PM +0000, Peter Dalgaard wrote: |> The 3.2.4 release had two annoyances which we would rather not have |> in

Hi all, I ran into a segfault while playing with dates. $ R --no-init-file ... > library(lubridate); d=as.POSIXlt(floor_date(Sys.time(),"year")); d$zone=NULL; d$zone=""; d Attaching package: ?lubridate? The following object is masked from ?package:base?: date Warning message: package ?lubridate? was built under R version 3.4.0

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

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 >

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

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

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 =

The 3.2.4-revised version turned out to give trouble for some of CRAN's subsystems. Accordingly, a rebadged version 3.2.5 is now released; it only differs in the version number and a few clean-up items. If you have a working install of 3.2.4-revised there should be no reason to upgrade it. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.2.5.tar.gz or wait for it

Hi all; I've already send a similar e-mail to the list and Prof. Brian Ripley answered me but my doubts remain unresolved. Thanks for the clarification, but perhaps I wasn't clear enough in posting my questions. I've got a postgres database which I read into R. The first column is Timestamp with timezone, and my data are already in UTC format. An 'printed' extract of R

Hello! I've been trying to get this right for quite a while now and fear there is an easy solution I just don't see. I did not have this problem in Linux, and I searched r-help and Google but did not find a solution, but of course I am grateful for and resources I might not have found our not understood yet. I try to parse a time stamp with time zone. I essentially just want to parse the

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

Full_Name: Allen McIntosh Version: 2.0.0 OS: RedHat 9.0 Submission from: (NULL) (67.80.175.118) The POSIX time printing routine gives strange results when asked to print a time that is exactly midnight: TZ=CST6CDT R -q --no-save > strptime("10/5/2004 00:00:01 CDT", "%m/%d/%Y %H:%M:%S %Z") [1] "2004-10-05 00:00:01" > strptime("10/5/2004 00:00:00

Hi, Is it possible to create a ts() object, whose data is daily based BUT measured only on working days? In other words, suppose I have a data set with 255 observations, measured from 29 June 1959 to 30 June 1960. How would I create such a data? I tried something like: ts(c(...), start(1959, 180)) but I'm not sure what to use for frequency. In other words I don't know how to

Hello, I am an advanced user of R. Recently I found out that apparently I do not fully understand vectors and lists fully Take this code snippet: T = c("02.03.2008 12:23", "03.03.2008 05:54") Times = strptime(T, "%d.%m.%Y %H:%M") Times # OK class(Times) # OK is.list(Times) # sort of understand and not understand that length(Times)

I am trying to build R-3.2.4 on an Oracle Enterprise Linux system, where I have previously built R-3.1.3 and predecessors without problems. I ran "./configure --with-x=no" ok. The make fails in src/extra/xz with what looks like a Makefile problem: liblzma.a: $(liblzma_a_OBJECTS) $rm -f $@ $(AR) -cr $@ $(liblzma_a_OBJECTS) $(RANLIB) $@ What I see in the make log is:

I have been struggling with this error message - and think I finally understand it's context. Start Line by line debugging shows me the function works: ... > saveRDS(val, mapfile) > val $variables $variables$IANA_HTTP_status_code_db [1] 0 1256 $variables$IANA_URI_scheme_db [1] 1256 3458 $variables$table_of_HTTP_status_codes [1] 4714 830 $references named list() $compressed

Hi Gabor and everybody; Thanks Gabor, with the alternative step you've told me the problem is resolved. Comparing the two procedures: Extract from the source 'character' data: > rain$ts[2039:2046] [1] "25/03/2000 22:00:00 UTC" "25/03/2000 23:00:00 UTC" [3] "26/03/2000 00:00:00 UTC" "26/03/2000 01:00:00 UTC" [5] "26/03/2000 02:00:00

I've been trying to build R 3.3.1 inside of a Nix environment on a Ubuntu 16.04 machine. It builds, but then it fails a regression test related to time zones, and I hope that someone could help me debug the problem. The failing test is in tests/reg-tests-rc.R (https://github.com/wch/r-source/blob/c3fe9cd4/tests/reg-tests-1c.R#L1577-L1587): ## format.POSIXlt() of Jan.1 if 1941 or '42 is

On 10 March 2016 at 08:51, Mick Jordan wrote: | I am trying to build R-3.2.4 on an Oracle Enterprise Linux system, where | I have previously built R-3.1.3 and predecessors without problems. I ran Well that is pretty much why R Core asks us to build early, and build often. | "./configure --with-x=no" ok. The make fails in src/extra/xz with what | looks like a Makefile problem: | |

This has to do with your own timezone. If I run that code on my computer, both formats are correct. If I do this after Sys.setenv(TZ = "UTC") Then: > cbind(format(dlt), format(dct)) [,1] [,2] [1,] "2016-12-06 21:45:41" "2016-12-06 20:45:41" [2,] "2016-12-06 21:45:42" "2016-12-06 20:45:42" The reason for that, is that