Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

anytime() behaves differently on Fedora #84

Closed
earowang opened this issue Nov 29, 2018 · 14 comments

Comments

Projects
None yet
2 participants
@earowang
Copy link

commented Nov 29, 2018

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.

@eddelbuettel

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

On the other hand:

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

This comment has been minimized.

Copy link
Author

commented Nov 29, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

@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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

@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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

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 packageUploading packagePreparing build, see status at
   http://builder.r-hub.io/status/anytime_0.3.3.tar.gz-78cb2e6ac2b64555af99dae9930a464bBuild startedDownloading and unpacking package fileQuerying system requirementsInstalling system requirementsStarting Docker containerQuerying package dependenciesInstalling package dependenciesRunning R CMD check
   About to run xvfb-run R CMD check anytime_0.3.3.tar.gzusing 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-8checking for fileanytime/DESCRIPTION’
─  checking extension type ... Packagethis is packageanytimeversion0.3.3’
─  package encoding: UTF-8checking package namespace informationchecking package dependencies (2s)
✔  checking if this is a source packagechecking if there is a namespacechecking for .dll and .exe fileschecking for hidden files and directorieschecking for portable file nameschecking for sufficient/correct file permissionschecking whether packageanytimecan be installed (20.9s)
✔  checking installed package sizechecking package directorycheckingbuilddirectorychecking DESCRIPTION meta-information (682ms)
✔  checking top-level fileschecking for left-over fileschecking index informationchecking package subdirectories (693ms)
✔  checking R files for non-ASCII characterschecking R files for syntax errorschecking whether the package can be loadedchecking whether the package can be loaded with stated dependencies (673ms)
✔  checking whether the package can be unloaded cleanlychecking whether the namespace can be loaded with stated dependencies (694ms)
✔  checking whether the namespace can be unloaded cleanlychecking loading without being on the library search pathchecking dependencies in R code (678ms)
✔  checking S3 generic/method consistency (674ms)
✔  checking replacement functionschecking foreign function calls (666ms)
✔  checking R code for possible problems (673ms)
✔  checking Rd fileschecking Rd metadatachecking Rd cross-references (668ms)
✔  checking for missing documentation entrieschecking for code/documentation mismatches (1.3s)
✔  checking Rd \usage sections (670ms)
✔  checking Rd contentschecking for unstated dependencies in exampleschecking line endings in shell scriptschecking line endings in C/C++/Fortran sources/headerschecking compiled codechecking sizes of PDF files underinst/doc’
✔  checking installed files frominst/doc’
✔  checking files invignettes’
✔  checking examples (684ms)
✔  checking for unstated dependencies intests’ (669ms)
─  checking tests ...
E  Runninggh_issue_84.RRunning the tests intests/gh_issue_84.Rfailed.
   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 haltedchecking for unstated dependencies in vignetteschecking package vignettes ininst/doc’
─  checking running R code from vignettes ...anytime-introduction.RmdusingUTF-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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

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

This comment has been minimized.

Copy link
Author

commented Nov 29, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2018

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

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

added a test script to investigate #84
issue seems installation-depedent so also added to .Rbuildignore
@earowang

This comment has been minimized.

Copy link
Author

commented Dec 6, 2018

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

This comment has been minimized.

Copy link
Owner

commented Dec 6, 2018

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

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

small addition to help page for Europe/London issue #84
as well as at least three other (referenced) issues
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.