similar to: POSIXlt$zone and $gmtoff questions

Displaying 20 results from an estimated 3000 matches similar to: "POSIXlt$zone and $gmtoff questions"

2020 Oct 23
0
The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?
?Hi again, I take advantage of my previous mail to ask you a question for which I was looking for an answer when detected the behaviour I previously told. In the help of DataTimeClasses one can read: "POSIXlt" objects will often have an attribute "tzone", a character vector of length 3 giving the time zone name from the TZ environment variable and the names of the base time
2016 Dec 06
1
segfault with POSIXlt zone=NULL zone=""
Hi Joshua, Thank you for minimizing my test case. > > Hope I'm not doing something illegal... > > > You are. You're changing the internal structure of a POSIXlt object > by re-ordering the list elements. You should not expect a malformed > POSIXlt object to behave as if it's correctly formed. You can see > it's malformed by comparing it's
2020 Oct 23
2
The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?
Dear all, I have just detected what seems a minor inconsistence with data types. If one unlists a POSIXlt time with GMT zone gets a numeric vector, since the POSIXlt list has no `zone` element, while if one unlists a POSIXlt time with a non GMT zone (also non specifying tz if the Sys.timezone is not GMT) gets a character vector due to including the `zone` element. > x <-
2016 Jan 27
0
Suggestions for improvement as regards `as` methods, and a call for consistency in `as.Date` methods
Good evening all, This topic is gone into at a bit more length at my related Stack Overflow question here: http://stackoverflow.com/questions/34647674/why-do-as-methods-remove-vector-names-and-is-there-a-way-around-it There are two lingering issues despite the abundant insight received at SO, namely: 1) _Why_ do as methods remove their arguments' names attribute? This is a fact which is
2014 Jun 04
2
error de incompatible methods
Hola Daniel, si perdona di a responder directamente y no me di cuenta. Ya se donde esta el error, pero queria preguntar si a puede ser que mi R funcione mal o algo porque esta manhana ejecute mi script y funciono perfectamente y ahora volvi a ejecutarlo y me volvio a dar el mismo problema de ayer , despues de reiniciar y demas el tinnR y el R, no se si me vacila o es que tengo algo mal en
2010 Jun 29
2
POSIXlt matching bug
I came across the below mis-feature/bug using match with POSIXlt objects (from strptime) in R 2.11.1 (though this appears to be an old issue). > x <- as.POSIXlt(Sys.Date()) > table <- as.POSIXlt(Sys.Date()+0:5) > length(x) [1] 1 > x %in% table # I expect TRUE [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE > match(x, table) # I expect 1 [1] NA NA NA NA NA NA NA NA
2012 Feb 08
0
Error in data.frame(srcfile = NA_character_ ...) using R CMD check
Hi all, I'm running into an error when using R CMD check on a package I inherited and I'm now trying to clean up. There are known issues with the Rd files (they definitely need to get updated) resulting in a couple of warnings, but the error occurs before check reaches the Rd files. Below is a snippet of my check.log: * using log directory 'F:/RForgePackages/pkg.Rcheck' * using R
2016 Dec 06
6
segfault with POSIXlt zone=NULL zone=""
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
2016 Dec 06
0
segfault with POSIXlt zone=NULL zone=""
On Tue, Dec 6, 2016 at 6:37 AM, <frederik at ofb.net> wrote: > 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 > If you're asking about a bug in R, you should provide a *minimal* reproducible
2016 Dec 06
1
segfault with POSIXlt zone=NULL zone=""
>>>>> Joshua Ulrich <josh.m.ulrich at gmail.com> >>>>> on Tue, 6 Dec 2016 09:51:16 -0600 writes: > On Tue, Dec 6, 2016 at 6:37 AM, <frederik at ofb.net> wrote: >> Hi all, >> >> I ran into a segfault while playing with dates. >> >> $ R --no-init-file >> ... >> >
2016 Dec 06
0
ok to segfault with POSIXlt zone=NULL zone=""?
Hi all, Here's a more minimal version of my earlier bug report (thanks, Joshua Ulrich): d=as.POSIXlt(Sys.time()); d$zone=NULL; d$zone=""; d I got some helpful, if glib, feedback from Joshua that the segfault may be caused by the changing of the order of the list elements in 'd' (representing the "internal structure" of the POSIXlt object). He seems to think that
2017 Oct 16
0
Another issue with Sys.timezone
>>>>> Stephen Berman <stephen.berman at gmx.net> >>>>> on Sun, 15 Oct 2017 01:53:12 +0200 writes: > (I reported the test failure mentioned below to R-help but was advised > that this list is the right one to address the issue; in the meantime I > investigated the matter somewhat more closely, including searching > recent R-devel
2017 Oct 19
0
Another issue with Sys.timezone
On Wed, 18 Oct 2017 18:09:41 +0200 Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>>> on Mon, 16 Oct 2017 19:13:31 +0200 writes: (I also included a reply to part of this response of yours below.) >>>>>> Stephen Berman <stephen.berman at gmx.net>
2020 Oct 02
0
timezone tests and R-devel
Thank you for the report. In R-devel, all.equal.POSIXt() by default reports inconsistent time zones. Previously, > x <- Sys.time() > all.equal(x, as.POSIXlt(x, tz = "EST5EDT")) would return TRUE. To ignore the time zone attributes in R-devel, the argument 'check.tzone = FALSE' needs to be used. That said, I can reproduce the 'make check' failure in R-devel on
2023 Nov 08
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
So, to summarize, the open questions are: (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) instead of NA_complex_? (2) Should the first argument in c(NA, x) and c(NA_integer_, x), where typeof(x) == "complex", be promoted to complex(r=NA_real_, i=0) instead of NA_complex_? My opinions: (1) No. The imaginary part of the
2020 Oct 23
0
timezone tests and R-devel
So let me try to raise this issue once more, and perhaps be more clear about what I think the issue is.. In my opinion there is now a bug in make check in R-development (tested today with r79361). As I see it, I specify a reasonable TZ environment variable and this leads to make check emitting an error. Best, Kasper On Fri, Oct 2, 2020 at 11:28 AM Kasper Daniel Hansen < kasperdanielhansen
2023 Nov 09
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
>>>>> Mikael Jagan >>>>> on Wed, 8 Nov 2023 11:13:18 -0500 writes: > So, to summarize, the open questions are: > (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) > instead of NA_complex_? > (2) Should the first argument in c(NA, x) and c(NA_integer_, x), > where typeof(x) == "complex", be promoted
2016 Jul 16
1
sample() fails with double or integer NA input of length one
Hi, I have discovered that sample() fails with an uninformative error message when the x argument is a single NA of type double or integer. I can reproduce the problem with the following code: base::sample(NA) # NA is of logical type above base::sample(NA_character_) base::sample(NA_complex_) base::sample(NA_real_) base::sample(NA_integer_) The last two lines throw the following error: Error
2011 Feb 03
1
bug in codetools/R CMD check?
Hi Mr Tierney, I have noticed an error message from R 1.12.x's CMD check for a while (apparently prof Ripley completely rewrote CMD check in R 1.12+) e.g.: http://bioconductor.org/checkResults/2.7/bioc-LATEST/snpMatrix/lamb2-checksrc.html ---------------- * checking R code for possible problems ... NOTE Warning: non-unique value when setting 'row.names': ?new? Error in
2020 Oct 01
3
timezone tests and R-devel
The return value of Sys.time() today with a timezone of US/Eastern is unchanged between 4.0.3-patched and devel, but on devel the following test fails all.equal(x, as.POSIXlt(x)) with x = Sys.time() This means that devel does not complete make tests (failure on tests/reg-tests-2.R) It is entirely possible that it is an error on my end, I use export TZ="US/Eastern" but I have been