False positive for inner_combine_linter() on timestamps with different formats

[MichaelChirico]

compare

c(as.POSIXct("2015-01-01",tz="UTC"), as.POSIXct("2015-01-02 01:02:03",tz="UTC"))
# [1] "2015-01-01 00:00:00 UTC" "2015-01-02 01:02:03 UTC"
as.POSIXct(c("2015-01-01", "2015-01-02 01:02:03"), tz="UTC")
# [1] "2015-01-01 UTC" "2015-01-02 UTC"

Without format= specified, as.POSIXct() guesses the format based on the first element --> infers %F in the latter case, in error.

It's maybe not the best default for as.POSIXct(), but IIRC it's as documented. The user can still get the desired behavior by giving matched formats on the input:

as.POSIXct(c("2015-01-01 00:00:00", "2015-01-02 01:02:03"), tz="UTC")
# [1] "2015-01-01 00:00:00 UTC" "2015-01-02 01:02:03 UTC"

But we also lint in dynamic cases:

lintr::lint(text = 'c(as.POSIXct(x), as.POSIXct(y))', linters = lintr::inner_combine_linter())
# <text>:1:1: warning: [inner_combine_linter] Combine inputs to vectorized functions first to take full advantage of vectorization, e.g., as.POSIXct(c(x, y)) only runs the more expensive as.POSIXct() once as compared to c(as.POSIXct(x), as.POSIXct(y)).
# c(as.POSIXct(x), as.POSIXct(y))
# ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

What's the best to do here? Just document the potential issue? Skip lints if there are non-CONST entries for timestamp converters? Then if there are CONST entries, try and run the comparison ourselves before throwing a lint?

[AshesITR]

I'd go for documenting it. This issue has never struck me in practice.