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 <seb.meyer at fau.de> 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 at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Best, Kasper [[alternative HTML version deleted]]
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 at 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 <seb.meyer at fau.de> 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 at r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> > >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > -- > Best, > Kasper >-- Best, Kasper [[alternative HTML version deleted]]
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 > <kasperdanielhansen at gmail.com <mailto:kasperdanielhansen at 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 <seb.meyer at fau.de > <mailto:seb.meyer at fau.de>> 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 at r-project.org <mailto:R-devel at r-project.org> mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > ______________________________________________ > R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Best, > Kasper > > > > -- > Best, > Kasper