extend checks for UTC inputs for robustness

[MichaelChirico]

Closes #4116

You can confirm all these timezones are the same like:

utc_tz = c("Etc/GMT", "Etc/UTC", "GMT", "GMT-0", "GMT+0", "GMT0", "UTC")
T0 = Sys.time() # ditto for .POSIXct(0) and .POSIXct(-1e6)
length(unique(sapply(utc_tz, function(tz) format(T0, tz=tz))))
# [1] 1

[MichaelChirico]

Really dunno why we're getting this on Travis, not able to reproduce:

<simpleError in if (tz == "UTC") {    z <- floor(unclass(x)/86400)    attr(z, "tzone") <- NULL    .Date(z)} else as.Date(as.POSIXlt(x, tz = tz)): argument is of length zero>

That snippet comes from base::as.Date.POSIXct and it should be from if (NULL == 'UTC') but the first tracing commit shows there was never a case of getting tz=NULL passed to as.Date.POSIXct

[codecov]

Codecov Report

Merging #4117 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master   #4117      +/-   ##
=========================================
+ Coverage    99.4%   99.4%   +<.01%     
=========================================
  Files          72      72              
  Lines       13685   13686       +1     
=========================================
+ Hits        13604   13605       +1     
  Misses         81      81

Impacted Files	Coverage Δ
R/IDateTime.R	100% <100%> (ø)	⬆️
R/utils.R	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d1c1b26...1f3666f. Read the comment docs.

[MichaelChirico]

I find this PR very strange in that the initial commit didn't work on Travis and the current commit does. any ideas?

[MichaelChirico]

difference in code is

if (is.null(tz)) tz=''
as.IDate(as.Date(x, tz = tz, ...))

vs

as.IDate(as.Date(x, tz =  if (is.null(tz)) tz='' else tz, ...))

I can't see how in the first one tz was passed as NULL to as.Date 🤔

[MichaelChirico]

I sorted this alphabetically... perhaps we should sort it by expected frequency instead? Does %chin% have a short-out to return once the first match is found?

[mattdowle]

No. Good idea. If its LHS is length 1, then it should just loop through the RHS and stop early if and when it is found. Will do. (Btw, sorting the input was good thought but doesn't make any difference as it's an order-n two-pass approach using the now-well- established truelength clobber technique.)

[mattdowle]

When %chin% does short-circuit as you suggested, then yes this input should be sorted by expected frequency. Good idea.

[mattdowle]

Done: #4121