[Rd] Issue with data() function

[Therneau, Terry M., Ph.D. via R-devel]

I found an issue with the data() command this evening when working on the 
survival package.

1. I have a lot of data sets in the package, almost all used in at least one 
vignette, 
help file, or test.  As a space saving measure, I have bundled many of them 
together, 
i.e., the file data/cancer.rda contains 19 data sets, many of them small. The 
resulting 
file (using xz compression) is quite a bit smaller than the individual ones.  
(I still get 
a warning note about size from R CMD check, but I'm no longer 2x the limit.)

2. Consider the lung data set.  All of these fail:
    data(lung)
    data("lung")
    data(lung, package="survival")

  a. The lung.Rd file had \usage{data(lung)}; that error was not caught by R 
CMD check.  
(Several other .Rd files as well.)

  b. In broader examples for teaching, I sometimes load data from other 
packages, e.g 
data(aidssi, package="mstate").  But this does not work for survival.  (The 
larger 
survival data sets that are in separate .rda files can be found.)

  c. What does work is survival::lung.  Might it be useful to add a comment to 
data.Rd to 
this effect?


3. Creating a separate package 'survivaldata' is of course one route, and is 
suggested in 
the "Writing R Extensions" guide.  But this is not possible since survival is a 
recommended package: it can't load any non-recommended package for it's tests 
or 
vignettes.  Longer term, perhaps there is way around this constraint?

Terry T.

-- 
Terry M Therneau, PhD
Department of Health Science Research
Mayo Clinic
thern...@mayo.edu

"TERR-ree THUR-noh"


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Change to I() in R 4.1

[Pages, Herve]

Hi there,

Is that change in R-devel intentional?

   library(Matrix)
   m <- as(matrix(c(0, 1)), "sparseMatrix")

   isS4(m)
   # [1] TRUE

   x <- I(m)
   # Warning message:
   # In `class<-`(x, unique.default(c("AsIs", oldClass(x :
   #   Setting class(x) to multiple strings ("AsIs", "dgCMatrix", ...); 
result will no longer be an S4 object

   isS4(x)
   # [1] FALSE

This works fine in R 4.0.3 i.e. no warning and I() doesn't turn off the 
S4 bit of the object.

This change breaks 17 Bioconductor packages.

Seems that the culprit is this change in how I() is implemented:

In R 4.0.3:

   > I
   function (x)
   {
 structure(x, class = unique(c("AsIs", oldClass(x
   }

In R devel:

   > I
   function (x)
   `class<-`(x, unique.default(c("AsIs", oldClass(x

Unfortunately there is a bunch of code around that calls I() on S4 
objects, admittedly not necessarily for very good reasons, but it 
happens. Would it be possible that I() has a less destructive effect on 
S4 objects?

Thanks,
H.

 > sessionInfo()
R Under development (unstable) (2020-10-17 r79346)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.1 LTS

Matrix products: default
BLAS:   /home/biocbuild/bbs-3.13-bioc/R/lib/libRblas.so
LAPACK: /home/biocbuild/bbs-3.13-bioc/R/lib/libRlapack.so

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] Matrix_1.2-18

loaded via a namespace (and not attached):
[1] compiler_4.1.0  grid_4.1.0  lattice_0.20-41

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] sum() (and similar methods) should work for zero row data.frames

[Pages, Herve]

Hi,

There are 2 bugs here. The proposed fix to Summary.data.frame() is fine 
but it doesn't address the other problem reported by the OP that 
as.matrix() on a zero-row data.frame doesn't respect the type of its 
columns, like other column-combining operations do:

   df <- data.frame(a=numeric(0), b=numeric(0))

   typeof(as.matrix(df))
   # [1] "logical"

   typeof(unlist(df))
   # [1] "double"

   typeof(do.call(c, df))
   # [1] "double"

I've run myself into this in a couple of occasions (not in the context 
of Summary methods) and worked around it with something like:

   as_matrix_data_frame <- function(df)
   {
 ans <- as.matrix(df)
 if (nrow(df) == 0L)
 storage.mode(ans) <- typeof(unlist(df))
 ans
   }

No reason as.matrix.data.frame() couldn't do something similar.

Cheers,
H.


On 10/20/20 09:36, Martin Maechler wrote:
>> mb706
>>  on Sun, 18 Oct 2020 22:14:55 +0200 writes:
> 
>  >> From my side: it would be great if you (or R core) could prepare a 
> patch, it would probably take me quite a bit longer than you since I don't 
> have experience creating patches for R.
> 
>  > Best, Martin
> 
> Basically, just
> 
> 1.  svn co 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.r-2Dproject.org_R_trunk&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YAI4LgZvkD5k-tPHUGFX4PEjm72-6j_WxHpkdHfe_3Q&s=PpmVRjh2Jrg07bLHjlbhdBgWQWAFe6RK_J2SivC74vw&e=
>R-devel
> 
> 2.  inside the R-devel source tree, find  src/library/base/R/dataframe.R
>  make the *minimal* changes there,
> 
>  (then also add some regression tests and update the help :-)
> 
> 3.  inside R-devel, do
> 
>  svn diff -x -ubw  >  mb706.patch
> 
> 4.  you've got the patch file  mb706.patch  which you could
>  attach to a bug report  on R's bugzilla
> 
>  (once you've got an account there ...
>   As you've asked for that *and* as you've proven your good
>   judgment about "true bug" vs. "not what I expected",
>   I'll create such an account for you now, in spite of the
>   fact that I'd still like to know a bit more than "Martin
>   mb706" about you  ...)
> 
> The changes have been committed to R-devel a quarter of an hour ago.
> We will keep them in R-devel (currently planned to become R
> 4.1.0 in spring 2021), and not port to the R-4.0.z branch, as
> the change is something like an API change, and also because
> nobody had ever reported this as an issue to our knowledge.
> 
> Thank you, Martin B706 for bringing the issue up,  and Gabe and Peter
> for chiming in !!
> 
> Best regards,
> Martin Maechler
> ETH Zurich  and  R core team
>  
> 
>  > On Sun, Oct 18, 2020, at 21:49, Gabriel Becker wrote:
>  >> Peter et al,
>  >>
>  >> I had the same thought, in particular for any() and all(), which in as
>  >> much as they should work on data.frames in the first place (which to 
> be
>  >> perfectly honest i do find quite debatable myself), should certainly
>  >> work on "logical" data.frames if they are going to work on "numeric"
>  >> ones.
>  >>
>  >> I can volunteer to prepare a patch if Martin (the reporter) did not
>  >> want to take a crack at it, and further if it is not already being 
> done
>  >> within R-core.
>  >>
>  >> Best,
>  >> ~G
>  >>
>  >> On Sun, Oct 18, 2020 at 12:19 AM peter dalgaard  
> wrote:
>  >> > Hmm, yes, this is probably wrong. E.g., we are likely to get 
> inconsistencies out of boundary cases like this
>  >> >
>  >> > > a <- na.omit(airquality)
>  >> > > sum(a)
>  >> > [1] 37495.3
>  >> > > sum(a[FALSE,])
>  >> > Error in FUN(X[[i]], ...) :
>  >> >   only defined on a data frame with all numeric variables
>  >> >
>  >> > Or, closer to an actual use case:
>  >> >
>  >> > > sum(subset(a, Ozone>100))
>  >> > [1] 3330.5
>  >> > > sum(subset(a, Ozone>200))
>  >> > Error in FUN(X[[i]], ...) :
>  >> >   only defined on a data frame with all numeric variables
>  >> >
>  >> >
>  >> > However, given that numeric summaries generally treat logicals as 
> 0/1, wouldn't it be easiest just to extend the check inside 
> Summary.data.frame with "&& !is.logical(x)"?
>  >> >
>  >> > > sum(as.matrix(a[FALSE,]))
>  >> > [1] 0
>  >> >
>  >> > -pd
>  >> >
>  >> > > On 17 Oct 2020, at 21:18 , Martin  wrote:
>  >> > >
>  >> > > The "Summary" group generics always throw errors for a data.frame 
> with zero rows, for example:
>  >> > >> sum(data.frame(x = numeric(0)))
>  >> > > #> Error in FUN(X[[i]], ...) :
>  >> > > #>   only defined on a data frame with all numeric variables
>  >> > > Same behaviour for min, max, any, all, ... . I believe this is 
> inconsistent with what these methods do for other empty objects (vectors, 
> matrices), where the return value is chosen to ensure transitivity: 
> sum(numeric(0)) == 0.
> 

Re: [Rd] The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?

[Sebastian Meyer]

Hi Iago,

I think the unlist behaviour is expected. If the list contains a mixture
of character and integer elements, the unlisted object will be a
character vector, similar to what happens when you c()oncatenate
components of different types (see the details in ?c for the hierarchy).
If you only need the numeric POSIXlt components anyway, you could do

unlist("$<-"(x, "zone", NULL))

to ensure that you get a numeric vector.
Alternatively, you can nicely do

as.data.frame(unclass(x))

to get all components in a data frame.

Concerning your second observation: Yes, the documentation of the
"tzone" attribute was wrong until very recently; I stumbled over this
exact trap one week ago and reported to R-core members. It has been
fixed in the development version (c79351) a few days ago and now says:

>   a character vector of length 3 giving the time zone name (from the 'TZ'
>   environment variable or argument 'tz' of functions creating
>   '"POSIXlt"' objects; '""' marks the current time zone)


Best regards,

Sebastian


Am 23.10.20 um 19:27 schrieb IAGO GINÉ VÁZQUEZ:
> ​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 zone and the alternate (daylight-saving) time zone. 
> Sometimes this may just be of length one, giving the time zone name.
> Then, I asked myself if the element `zone` of POSIXlt could be different of 
> the attribute `tzone`. But I do not get that. I am not sure of understanding 
> what the "time zone name from the TZ environment variable" is if not what I 
> set through `Sys.setenv(TZ = "")`. But the next example does not behave as I 
> would expect:
> 
>> Sys.setenv(TZ = "EDT")
>> x <- as.POSIXlt(Sys.time(), "CET")
> 
>> x[1,"zone"]
> [1] "CEST"
> 
>> attributes(x) $names  [1] "sec""min""hour"   "mday"   "mon"
>> "year"   "wday"   "yday"   "isdst"  "zone"   "gmtoff" $class [1] "POSIXlt" 
>> "POSIXt" $tzone [1] "CET"  "CET"  "CEST"
> 
> So `x[1,"zone"]` is what I expect, but I would expect `attributes(x)$tzone` 
> would be related to `TZ = "EDT"`, and not to `tz = "CET"`. So, what am I 
> understanding wrongly?
> 
> Thank you!
> Stay safe,
> 
> 
> Iago
> 
> 
> De: R-devel  de part de IAGO GINÉ VÁZQUEZ 
> 
> Enviat el: divendres, 23 d’octubre de 2020 19:03
> Per a: r-devel@r-project.org 
> Tema: [Rd] 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 <- as.POSIXlt(Sys.time(), "GMT")
>> (y <- unlist(x))
>   sec   min  hour  mday   mon  year  wday  
> yday isdst
>  54.99715  26.0  16.0  23.0   9.0 120.0   5.0 
> 296.0   0.0
>> str(y)
>  Named num [1:9] 55 26 16 23 9 ...
>  - attr(*, "names")= chr [1:9] "sec" "min" "hour" "mday" ...
> 
>> x <- as.POSIXlt(Sys.time(), "CET")
>> (y <- unlist(x))
>secmin   hour   mday   
>  mon   year   wday   yday
> "19.5111262798309"   "27"   "18"   "23"   
>  "9"  "120""5"  "296"
>  isdst   zone gmtoff
>"1" "CEST" "7200"
>> str(y)
>  Named chr [1:11] "19.5111262798309" "27" "18" "23" "9" "120" "5" "296" "1" 
> "CEST" "7200"
>  - attr(*, "names")= chr [1:11] "sec" "min" "hour" "mday" ...
> 
> Is it expected? Why do not include always `zone` as an element of POSIXlt? 
> Should POSIXlt objects be unlisted in a different way?
> Thank you!
> Best regards,
> 
> Iago
> 
> PS: I was using R 4.0.3. I don't know if this behaviour already changed in 
> R-devel. Excuse me in that case.
> 
> 
> [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

-- 
Dr. Sebastian Meyer
Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU)
Institut für Medizininformatik, Biometrie und Epidemiologie

Re: [Rd] The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?

[IAGO GINÉ VÁZQUEZ]

​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 zone and the alternate (daylight-saving) time zone. 
Sometimes this may just be of length one, giving the time zone name.
Then, I asked myself if the element `zone` of POSIXlt could be different of the 
attribute `tzone`. But I do not get that. I am not sure of understanding what 
the "time zone name from the TZ environment variable" is if not what I set 
through `Sys.setenv(TZ = "")`. But the next example does not behave as I would 
expect:

> Sys.setenv(TZ = "EDT")
> x <- as.POSIXlt(Sys.time(), "CET")

> x[1,"zone"]
[1] "CEST"

> attributes(x) $names  [1] "sec""min""hour"   "mday"   "mon""year" 
>   "wday"   "yday"   "isdst"  "zone"   "gmtoff" $class [1] "POSIXlt" "POSIXt" 
> $tzone [1] "CET"  "CET"  "CEST"

So `x[1,"zone"]` is what I expect, but I would expect `attributes(x)$tzone` 
would be related to `TZ = "EDT"`, and not to `tz = "CET"`. So, what am I 
understanding wrongly?

Thank you!
Stay safe,


Iago


De: R-devel  de part de IAGO GINÉ VÁZQUEZ 

Enviat el: divendres, 23 d’octubre de 2020 19:03
Per a: r-devel@r-project.org 
Tema: [Rd] 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 <- as.POSIXlt(Sys.time(), "GMT")
> (y <- unlist(x))
  sec   min  hour  mday   mon  year  wday  yday 
isdst
 54.99715  26.0  16.0  23.0   9.0 120.0   5.0 296.0 
  0.0
> str(y)
 Named num [1:9] 55 26 16 23 9 ...
 - attr(*, "names")= chr [1:9] "sec" "min" "hour" "mday" ...

> x <- as.POSIXlt(Sys.time(), "CET")
> (y <- unlist(x))
   secmin   hour   mday 
   mon   year   wday   yday
"19.5111262798309"   "27"   "18"   "23" 
   "9"  "120""5"  "296"
 isdst   zone gmtoff
   "1" "CEST" "7200"
> str(y)
 Named chr [1:11] "19.5111262798309" "27" "18" "23" "9" "120" "5" "296" "1" 
"CEST" "7200"
 - attr(*, "names")= chr [1:11] "sec" "min" "hour" "mday" ...

Is it expected? Why do not include always `zone` as an element of POSIXlt? 
Should POSIXlt objects be unlisted in a different way?
Thank you!
Best regards,

Iago

PS: I was using R 4.0.3. I don't know if this behaviour already changed in 
R-devel. Excuse me in that case.


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?

[IAGO GINÉ VÁZQUEZ]

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 <- as.POSIXlt(Sys.time(), "GMT")
> (y <- unlist(x))
  sec   min  hour  mday   mon  year  wday  yday 
isdst
 54.99715  26.0  16.0  23.0   9.0 120.0   5.0 296.0 
  0.0
> str(y)
 Named num [1:9] 55 26 16 23 9 ...
 - attr(*, "names")= chr [1:9] "sec" "min" "hour" "mday" ...

> x <- as.POSIXlt(Sys.time(), "CET")
> (y <- unlist(x))
   secmin   hour   mday 
   mon   year   wday   yday
"19.5111262798309"   "27"   "18"   "23" 
   "9"  "120""5"  "296"
 isdst   zone gmtoff
   "1" "CEST" "7200"
> str(y)
 Named chr [1:11] "19.5111262798309" "27" "18" "23" "9" "120" "5" "296" "1" 
"CEST" "7200"
 - attr(*, "names")= chr [1:11] "sec" "min" "hour" "mday" ...

Is it expected? Why do not include always `zone` as an element of POSIXlt? 
Should POSIXlt objects be unlisted in a different way?
Thank you!
Best regards,

Iago

PS: I was using R 4.0.3. I don't know if this behaviour already changed in 
R-devel. Excuse me in that case.


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] timezone tests and R-devel

[Sebastian Meyer]

Yes, you are absolutely right and I'm pretty sure this will be fixed in
one way or another.

IMO, the failing test should simply use all.equal.POSIXt's new argument
check.tzone=FALSE.

Two simple alternatives modifying all.equal.POSIXt behaviour:

- make check.tzone=FALSE the default: this is inconsistent with other
arguments of all.equal methods, always defaulting to stricter checks

- let all.equal.POSIXt generally ignore the tzone difference if tzone is
unset for one of the objects (similar to check_tzones): I think this is
a bad idea because tzone affects how POSIXt objects are printed, and
under check.tzone=TRUE, two objects shouldn't be considered "nearly
equal" if they print differently.

Best regards,

Sebastian


Am 23.10.20 um 10:28 schrieb Kasper Daniel Hansen:
> 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
> mailto:kasperdanielhan...@gmail.com>> wrote:
> 
> Yes, the potential issue I see is that 
>   make check 
> fails when I explicitly set TZ. However, I set it to be the same as
> what the system reports when I login.
> 
> Details: The system (RHEL) I am working on has
> $ strings /etc/localtime | tail -n 1
> EST5EDT,M3.2.0,M11.1.0
> $ date +%Z
> EDT
> $ echo $TZ
> US/Eastern
> 
> 
> 
> On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer  > wrote:
> 
> 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 Ubuntu
> Linux when TZ is set, even if it is set to the system time zone:
> 
> $ export TZ=Europe/Berlin
> $ make check
> [...]
> > running code in '../../tests/reg-tests-2.R' ... OK
> >   comparing 'reg-tests-2.Rout' to
> '../../tests/reg-tests-2.Rout.save' ...7335c7335
> > < [1] "'tzone' attributes are inconsistent ('' and
> 'Europe/Berlin')"
> > ---
> >> [1] TRUE
> 
> 
> Compare the following two sessions:
> 
> > R-devel --vanilla --no-echo -e 'Sys.timezone(); x <-
> Sys.time(); all.equal(x, as.POSIXlt(x))'
> [1] "Europe/Berlin"
> [1] TRUE
> 
> > TZ='Europe/Berlin' R-devel --vanilla --no-echo -e
> 'Sys.timezone(); x <- Sys.time(); all.equal(x, as.POSIXlt(x))'
> [1] "Europe/Berlin"
> [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
> 
> 
> So as.POSIXlt() sets a 'tzone' attribute if TZ is set, but this
> behaviour is not new. Even with old R 3.6.3, I see
> 
> > R-3.6.3 --vanilla --slave -e 'attr(as.POSIXlt(Sys.time()),
> "tzone")'
> [1] ""     "CET"  "CEST"
> 
> > TZ='Europe/Berlin' R-3.6.3 --vanilla --slave -e
> 'attr(as.POSIXlt(Sys.time()), "tzone")'
> [1] "Europe/Berlin" "CET"           "CEST"
> 
> This might be system-specific.
> 
> I suggest to modify the test as attached for make check to pass
> in this
> setting.
> 
> Best regards,
> 
>         Sebastian
> 
> 
> Am 01.10.20 um 20:31 schrieb Kasper Daniel Hansen:
> > 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 using this for a while, and R-4.0.3-patched
> built today
> > passes make tests.
> >
> > Details below, and I am happy to provide more information.
> >
> > Build platform: inside a conda environment on linux. I have
> been doing this
> > for a while, but it is certainly a non-standard setup. GCC 7.3
> >
> > Best,
> > Kasper
> >
> > On R version 4.0.3 beta (2020-10-01 r79286) I get
> >
> >> x = Sys.time()
> >> attributes(x)
> > $class
> > [1] "POSIXct" "POSIXt"
> 

Re: [Rd] timezone tests and R-devel

[Kasper Daniel Hansen]

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 <
kasperdanielhan...@gmail.com> wrote:

> Yes, the potential issue I see is that
>   make check
> fails when I explicitly set TZ. However, I set it to be the same as what
> the system reports when I login.
>
> Details: The system (RHEL) I am working on has
> $ strings /etc/localtime | tail -n 1
> EST5EDT,M3.2.0,M11.1.0
> $ date +%Z
> EDT
> $ echo $TZ
> US/Eastern
>
>
>
> On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer  wrote:
>
>> 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 Ubuntu
>> Linux when TZ is set, even if it is set to the system time zone:
>>
>> $ export TZ=Europe/Berlin
>> $ make check
>> [...]
>> > running code in '../../tests/reg-tests-2.R' ... OK
>> >   comparing 'reg-tests-2.Rout' to '../../tests/reg-tests-2.Rout.save'
>> ...7335c7335
>> > < [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
>> > ---
>> >> [1] TRUE
>>
>>
>> Compare the following two sessions:
>>
>> > R-devel --vanilla --no-echo -e 'Sys.timezone(); x <- Sys.time();
>> all.equal(x, as.POSIXlt(x))'
>> [1] "Europe/Berlin"
>> [1] TRUE
>>
>> > TZ='Europe/Berlin' R-devel --vanilla --no-echo -e 'Sys.timezone(); x <-
>> Sys.time(); all.equal(x, as.POSIXlt(x))'
>> [1] "Europe/Berlin"
>> [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
>>
>>
>> So as.POSIXlt() sets a 'tzone' attribute if TZ is set, but this
>> behaviour is not new. Even with old R 3.6.3, I see
>>
>> > R-3.6.3 --vanilla --slave -e 'attr(as.POSIXlt(Sys.time()), "tzone")'
>> [1] "" "CET"  "CEST"
>>
>> > TZ='Europe/Berlin' R-3.6.3 --vanilla --slave -e
>> 'attr(as.POSIXlt(Sys.time()), "tzone")'
>> [1] "Europe/Berlin" "CET"   "CEST"
>>
>> This might be system-specific.
>>
>> I suggest to modify the test as attached for make check to pass in this
>> setting.
>>
>> Best regards,
>>
>> Sebastian
>>
>>
>> Am 01.10.20 um 20:31 schrieb Kasper Daniel Hansen:
>> > 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 using this for a while, and R-4.0.3-patched built today
>> > passes make tests.
>> >
>> > Details below, and I am happy to provide more information.
>> >
>> > Build platform: inside a conda environment on linux. I have been doing
>> this
>> > for a while, but it is certainly a non-standard setup. GCC 7.3
>> >
>> > Best,
>> > Kasper
>> >
>> > On R version 4.0.3 beta (2020-10-01 r79286) I get
>> >
>> >> x = Sys.time()
>> >> attributes(x)
>> > $class
>> > [1] "POSIXct" "POSIXt"
>> >
>> >> attributes(as.POSIXlt(x))
>> > $names
>> >  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"
>>  "yday"
>> >  [9] "isdst"  "zone"   "gmtoff"
>> >
>> > $class
>> > [1] "POSIXlt" "POSIXt"
>> >
>> > $tzone
>> > [1] "US/Eastern" "EST""EDT"
>> >
>> >> all.equal(x, as.POSIXlt(x))
>> > [1] TRUE
>> >
>> > On R Under development (unstable) (2020-10-01 r79286) I get
>> >> x = Sys.time()
>> >> all.equal(x,x)
>> > [1] TRUE
>> >> attributes(as.POSIXlt(x))
>> > $names
>> >  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"
>>  "yday"
>> >  [9] "isdst"  "zone"   "gmtoff"
>> >
>> > $class
>> > [1] "POSIXlt" "POSIXt"
>> >
>> > $tzone
>> > [1] "US/Eastern" "EST""EDT"
>> >
>> >> all.equal(x, as.POSIXlt(x))
>> > [1] "'tzone' attributes are inconsistent ('' and 'US/Eastern')"
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
> --
> Best,
> Kasper
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel