[R] Update the as.Date() binding

[asfimport]

Reporter: Dragoș Moldovan-Grünfeld / @dragosmg
Assignee: Dragoș Moldovan-Grünfeld / @dragosmg

Subtasks:

• [R] Update as.Date() to support an origin different from epoch
• [R] Improve as.Date() error message when supplying several tryFormats
• [R] Update as.Date() to support a timezone different from "UTC"

Related issues:

• [R] lubridate functions for 9.0.0 (is a child of)

_{Note: This issue was originally created as ARROW-15805. Please see the migration documentation for further details.}

[asfimport]

Jonathan Keane / @jonkeane:
This is alluded to in the PR comments, but taking a step back and thinking about the behavior:

dates_dash_first <- c("2022-01-01", "2022/02/02", "2022/02/02", "2022/02/02", "2022-01-01", "2022-01-01")
dates_slash_first <- c("2022/02/02", "2022-01-01", "2022/02/02", "2022/02/02", "2022-01-01", "2022-01-01")

as.Date(dates_dash_first, tryFormats = c("%Y-%m-%d", "%Y/%m/%d"))
#> [1] "2022-01-01" NA           NA           NA           "2022-01-01"
#> [6] "2022-01-01"

as.Date(dates_slash_first, tryFormats = c("%Y-%m-%d", "%Y/%m/%d"))
#> [1] "2022-02-02" NA           "2022-02-02" "2022-02-02" NA          
#> [6] NA

Which format is chosen and used is dependent on the underlying data, and critically the order that data is in. Given that we can't always guaranty the order of the data we are processing[1] we should not attempt to implement this behavior right now.

Instead, we should have an error message if someone tries to specify tryFormats suggesting that they might use lubridate::as_date() if they want to specify multiple formats (and can accept that you don't get NAs for all formats other than the first that matches), or they should pick which format they want to use and use that.

[1] and even if we could, it would take some tricky expression writing to pick the right format

[asfimport]

Dragoș Moldovan-Grünfeld / @dragosmg:
I totally agree. 

[asfimport]

Dragoș Moldovan-Grünfeld / @dragosmg:
I think a message advising users to try the dedicated date/time parsing functionality might be better than pointing them to {}lubridate::as_date(){}. I have implemented that in #13070 Happy to change it.

lubridate::as_date() documentation and source code does not indicate it would accept multiple formats. If the user would like to try several formats, I believe the best course of action would be to use lubridate's date/time parsing functionality.