anytime() behaves differently on Fedora #84

earowang · 2018-11-29T03:48:11Z

Hi Dirk,

I've been notified that some unit tests in the tsibble package failed on platform fedora-clang-devel. It seems to be related to anytime().

The following lines return "2018-10-01 UTC" on macOS and ubuntu (systems that I have tested locally), which is as expected. But they all give 2018-10-01 01:00:00 UTC on fedora instead.

anytime::utctime("2018-10", tz = "UTC")
anytime::utctime("2018-10-01", tz = "UTC")
anytime::utctime("2018-10-01 00", tz = "UTC")
anytime::utctime("2018-10-01 00:00", tz = "UTC")
anytime::utctime("2018-10-01 00:00:00", tz = "UTC")

I don't have access to fedora, so it's hard to reproduce and backtrace the error. I've created a tiny repo/package here and tested it using rhub::check_on_fedora(). All the lines above failed. Since it is set to "UTC", doesn't look like time zones issue.

* checking tests ...
  Running ‘testthat.R’
 ERROR
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
  ── 5. Failure: utctime2 (@test-utctime.R#10)  ──────────────────────────────────
  anytime::utctime("2018-10-01 00:00:00", tz = "UTC") not identical to `y`.
  1/1 mismatches
  [1] 2018-10-01 01:00:00 - 2018-10-01 == 1 hours
  
  ══ testthat results  ═══════════════════════════════════════════════════════════
  OK: 0 SKIPPED: 0 FAILED: 5
  1. Failure: utctime2 (@test-utctime.R#6) 
  2. Failure: utctime2 (@test-utctime.R#7) 
  3. Failure: utctime2 (@test-utctime.R#8) 
  4. Failure: utctime2 (@test-utctime.R#9) 
  5. Failure: utctime2 (@test-utctime.R#10) 
  
  Error: testthat unit tests failed
  Execution halted

Thanks.

The text was updated successfully, but these errors were encountered:

eddelbuettel · 2018-11-29T03:55:03Z

Ewwww. That looks bad ... for Boost.

I would, in the narrow sense, try to avoid the test to avoid the error at CRAN. That is clearly a parser bug hence an issue with the Boost version. Do we know / can we know i) what the Fedora version is and ii) what the Boost version is? We may be able to coax your test package to tell us.

Try adding useR=TRUE just to "prove" it's Boost. By setting that flag we use the R parser (which I export via package RApiDatetime).

eddelbuettel · 2018-11-29T04:01:23Z

On the other hand:

anytime passes all checks on all systems at CRAN
anytime uses BH and that should bring a standard version in (though I know in Debian we cheat and defer to system Boost)

earowang · 2018-11-29T04:34:30Z

Updates:

looks like it is related to Boost, useR = TRUE corrects the problem. But anytime::utctime("2018-10", tz = "UTC", useR = TRUE) returns NA not 2018-10-01 from Boost.
rhub uses the latest Fedora according to https://hub.docker.com/r/rhub/fedora-gcc-devel/, not sure about the Boost version.
Tests on Fedora 29 with r-release and works fine.

eddelbuettel · 2018-11-29T11:45:34Z

Thanks for the follow-up! Briefly:

yes, the NA is expected, you get the same in R, a day is NOT filled in by default
could it be local to rhub? Other people use Fedora
thanks for testing on FC 29

eddelbuettel · 2018-11-29T12:10:39Z

@gaborcsardi Quick Q for you: anything different or special on RHub's fedora-gcc-devel? Newer Boost version? I keep looking at their release announcement in light of a possible update for our BH package but nothing jumped at me yet.

eddelbuettel · 2018-11-29T12:13:16Z

@earowang One other though: the difference is exactly one hour. That smells like a timezone / dst adjustment. Can you maybe try with a different date (ie month or year) and see if it passes?

eddelbuettel · 2018-11-29T12:25:32Z

FWIW this passes for me with R-release and R-devel:

edd@rob:~/git/anytime/tests$ cat gh_issue_84.R
expected <- "2018-10-01"
stopifnot(expected == format(anytime::utctime("2018-10", tz = "UTC")))
stopifnot(expected == format(anytime::utctime("2018-10-01", tz = "UTC")))
stopifnot(expected == format(anytime::utctime("2018-10-01 00", tz = "UTC")))
stopifnot(expected == format(anytime::utctime("2018-10-01 00:00", tz = "UTC")))
stopifnot(expected == format(anytime::utctime("2018-10-01 00:00:00", tz = "UTC")))
edd@rob:~/git/anytime/tests$

Not that the formating is slightly different due to what R does with POSIXct when print-ing versus format-ing.

eddelbuettel · 2018-11-29T12:35:00Z

And that test file fails on fedora: https://builder.r-hub.io/status/anytime_0.3.3.tar.gz-78cb2e6ac2b64555af99dae9930a464b

R> check(".", platform="fedora-gcc-devel")
─  Building package
─  Uploading package
─  Preparing build, see status at
   http://builder.r-hub.io/status/anytime_0.3.3.tar.gz-78cb2e6ac2b64555af99dae9930a464b
─  Build started
─  Downloading and unpacking package file
─  Querying system requirements
─  Installing system requirements
─  Starting Docker container
─  Querying package dependencies
─  Installing package dependencies
─  Running R CMD check
   About to run xvfb-run R CMD check anytime_0.3.3.tar.gz
─  using log directory ‘/home/docker/anytime.Rcheck’ (4.1s)
─  using R Under development (unstable) (2018-11-25 r75668)
─  using platform: x86_64-pc-linux-gnu (64-bit)
─  using session charset: UTF-8
✔  checking for file ‘anytime/DESCRIPTION’
─  checking extension type ... Package
─  this is package ‘anytime’ version ‘0.3.3’
─  package encoding: UTF-8
✔  checking package namespace information
✔  checking package dependencies (2s)
✔  checking if this is a source package
✔  checking if there is a namespace
✔  checking for .dll and .exe files
✔  checking for hidden files and directories
✔  checking for portable file names
✔  checking for sufficient/correct file permissions
✔  checking whether package ‘anytime’ can be installed (20.9s)
✔  checking installed package size
✔  checking package directory
✔  checking ‘build’ directory
✔  checking DESCRIPTION meta-information (682ms)
✔  checking top-level files
✔  checking for left-over files
✔  checking index information
✔  checking package subdirectories (693ms)
✔  checking R files for non-ASCII characters
✔  checking R files for syntax errors
✔  checking whether the package can be loaded
✔  checking whether the package can be loaded with stated dependencies (673ms)
✔  checking whether the package can be unloaded cleanly
✔  checking whether the namespace can be loaded with stated dependencies (694ms)
✔  checking whether the namespace can be unloaded cleanly
✔  checking loading without being on the library search path
✔  checking dependencies in R code (678ms)
✔  checking S3 generic/method consistency (674ms)
✔  checking replacement functions
✔  checking foreign function calls (666ms)
✔  checking R code for possible problems (673ms)
✔  checking Rd files
✔  checking Rd metadata
✔  checking Rd cross-references (668ms)
✔  checking for missing documentation entries
✔  checking for code/documentation mismatches (1.3s)
✔  checking Rd \usage sections (670ms)
✔  checking Rd contents
✔  checking for unstated dependencies in examples
✔  checking line endings in shell scripts
✔  checking line endings in C/C++/Fortran sources/headers
✔  checking compiled code
✔  checking sizes of PDF files under ‘inst/doc’
✔  checking installed files from ‘inst/doc’
✔  checking files in ‘vignettes’
✔  checking examples (684ms)
✔  checking for unstated dependencies in ‘tests’ (669ms)
─  checking tests ...
E  Running ‘gh_issue_84.R’
   Running the tests in ‘tests/gh_issue_84.R’ failed.
   Complete output:
     > expected <- "2018-10-01"
     > stopifnot(expected == format(anytime::utctime("2018-10", tz = "UTC")))
     Error: expected == format(anytime::utctime("2018-10", tz = "UTC")) is not TRUE
     Execution halted
✔  checking for unstated dependencies in vignettes
✔  checking package vignettes in ‘inst/doc’
─  checking running R code from vignettes ...
      ‘anytime-introduction.Rmd’ using ‘UTF-8’ ... OK
    NONE
W  checking re-building of vignette outputs (1.3s)
   Error in re-building vignettes:
     ...
   ! LaTeX Error: File `extarticle.cls' not found.

   ! Emergency stop.
   <read *>

   Error: processing vignette 'anytime-introduction.Rmd' failed with diagnostics:
   Failed to compile anytime-introduction.tex. See anytime-introduction.log for more info.
   Execution halted

✔  checking PDF version of manual (2.7s)

─  Done with R CMD check
─  Saving artifacts

R>

So my inclination would be not to run the test if I were you. This seems like a bug, or change in behaviour, across platforms so til we know more ... I'd skip it.

eddelbuettel · 2018-11-29T16:35:36Z

The following RHub run was successful:
https://builder.r-hub.io/status/anytime_0.3.3.1.tar.gz-73d07faaea8848e2a2cb414b529907e9

It uses the following code which I may commit to the package as tests/gh_issue_84.R.

si <- sessionInfo()
if (!grepl("Fedora", si$running, ignore.case=TRUE)) {
    expected <- "2018-10-01"
    stopifnot(expected == format(anytime::utctime("2018-10", tz = "UTC")))
    stopifnot(expected == format(anytime::utctime("2018-10-01", tz = "UTC")))
    stopifnot(expected == format(anytime::utctime("2018-10-01 00", tz = "UTC")))
    stopifnot(expected == format(anytime::utctime("2018-10-01 00:00", tz = "UTC")))
    stopifnot(expected == format(anytime::utctime("2018-10-01 00:00:00", tz = "UTC")))
}

I suggest you do something similar to avoid your breakage. I have no means to influence or access the CRAN test machines so my current approach is ... error avoidance as I cannot work on fixing this without access.

eddelbuettel · 2018-11-29T22:48:10Z

I also see it on one other machine at RHub. I may be a matter of

zoneinfo missing
TZ or timezone not set

But without access it is hard to say more. So maybe best to avoid the test. I've had to do the same for some tests with timezones.

earowang · 2018-11-29T22:52:22Z

Thanks Dirk. I'll skip the tests on Fedora. I've also tried dates other than 2018-10-01, and they all failed. Kurt wrote to me "Apparently the time zones make a difference ...".

eddelbuettel · 2018-11-29T22:55:30Z

I was wondering about the effect of Oct 1 as well, good that you tested it.

FWIW the other RHub fail was on Ubunty 16.04. I then had a hunch and fired up a Docker container (with Rocker's r-base), installed anytime and ... it also worked. Given how painful another iteration at CRAN can be I'd skip the test alltogether. Suboptimal, but life goes on...

issue seems installation-depedent so also added to .Rbuildignore

earowang · 2018-12-06T10:36:23Z

Hi Dirk,

Looks like time zones indeed make a difference. Skipping the tests on Fedora probably isn't a solution.

Tested on macOS:

Sys.setenv(TZ = "Europe/London")
x <- c("2016-01-01 00:00", "2016-10-01 00:00", 
       "2016-12-09 00:00", "2016-12-09 10:00")
anytime::utctime(x, tz = "UTC")
#> [1] "2016-01-01 01:00:00 UTC" "2016-10-01 01:00:00 UTC"
#> [3] "2016-12-09 01:00:00 UTC" "2016-12-09 11:00:00 UTC"

Sys.setenv(TZ = "Australia/Melbourne")
x <- c("2016-01-01 00:00", "2016-10-01 00:00", 
       "2016-12-09 00:00", "2016-12-09 10:00")
anytime::utctime(x, tz = "UTC")
#> [1] "2016-01-01 00:00:00 UTC" "2016-10-01 00:00:00 UTC"
#> [3] "2016-12-09 00:00:00 UTC" "2016-12-09 10:00:00 UTC"

^{Created on 2018-12-06 by the reprex package (v0.2.1)}

eddelbuettel · 2018-12-06T11:46:51Z

Thanks for the follow-up. Skipping the test alltogether may be :-/

as well as at least three other (referenced) issues

eddelbuettel closed this as completed Nov 29, 2018

eddelbuettel added a commit that referenced this issue Nov 30, 2018

added a test script to investigate #84

8449640

issue seems installation-depedent so also added to .Rbuildignore

eddelbuettel added a commit that referenced this issue Dec 9, 2018

small addition to help page for Europe/London issue #84

375e77c

as well as at least three other (referenced) issues

eddelbuettel mentioned this issue Dec 9, 2018

one hour difference for "Europe/London" #86

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

anytime() behaves differently on Fedora #84

anytime() behaves differently on Fedora #84

earowang commented Nov 29, 2018 •

edited

Loading

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018 •

edited

Loading

earowang commented Nov 29, 2018 •

edited

Loading

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

earowang commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

earowang commented Dec 6, 2018

eddelbuettel commented Dec 6, 2018

anytime() behaves differently on Fedora #84

anytime() behaves differently on Fedora #84

Comments

earowang commented Nov 29, 2018 • edited Loading

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018 • edited Loading

earowang commented Nov 29, 2018 • edited Loading

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

earowang commented Nov 29, 2018

eddelbuettel commented Nov 29, 2018

earowang commented Dec 6, 2018

eddelbuettel commented Dec 6, 2018

earowang commented Nov 29, 2018 •

edited

Loading

eddelbuettel commented Nov 29, 2018 •

edited

Loading

earowang commented Nov 29, 2018 •

edited

Loading