similar to: strftime fails on POSIXct objects (PR#10695)

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

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 >

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

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

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

Don, thanks for your report. On Jan 19, 2005, at 12:41 PM, Don MacQueen wrote: > I'm encountering a problem formatting POSIXct objects in R 2.0.1 on OS > X. > > For reference, on a Solaris system, R 2.0.1 (2004-11-15), formatting > is correct: > >> Sys.time() > [1] "2005-01-19 09:12:33 PST" >> format(Sys.time(),'%H:%M %Z') > [1]

Dear list, When using as.POSIXlt with times measured down to microseconds the default format.POSIXlt seems to cause some possibly undesirable behaviour: According to the code in format.POSIXlt the maximum accuracy of printing fractional seconds is 1 microsecond, but if I do; options( digits.secs = 6 ) as.POSIXlt( 1.000002 , tz="", origin="1970-01-01") as.POSIXlt( 1.999998 ,

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

The 3.2.4 release had two annoyances which we would rather not have in an "ultra-stable" release, designed to hang around for the duration of the 3.3 series. One was a relatively minor Makefile issue affecting system using R's bundled lzma library. The other, rather more serious, affected printing and formatting of POSIXlt objects, which would unpredictably get the Daylight Savings

Hello Could anyone explain me the difference between strftime vs strptime, please ? I've read the help but it's a little bit cionfusing for me. cheers -- View this message in context: http://r.789695.n4.nabble.com/strftime-vs-strptime-tp3018865p3018865.html Sent from the R help mailing list archive at Nabble.com.

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

On Sun, 11 Jan 2004, Dirk Eddelbuettel wrote: > On Fri, Jan 09, 2004 at 06:01:27PM +0100, christoph.schmutz@meteoschweiz.ch wrote: > > Full_Name: Christoph Schmutz, MeteoSchweiz, Switzerland > > Version: R1.7.1, R1.8.1 > > OS: windows2000, solaris sunOS 5.8 > > Submission from: (NULL) (141.249.133.6) > > > > > > > > I'm not sure if I

Dear R experts.. I am trying to understand what exactly strptime and strftime do... Where can I look for the detailed notes on these two functions? In addition, how POSIX functions like POSIXct and POSIXlt are used in these functions? Regards, Santosh [[alternative HTML version deleted]]

Hi I have many excel files were the Date field was not declared as date, so the dates look like this: 1/2/1978 I know that the format is day/month/year How can I make R change this to Date format? If I use strftime, I get wrong dates: dataset=c("1/2/1978") strftime(dataset,"%d/%m/%Y") "19/02/0001" Thanks in advance.

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

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

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