Oh, and just as I send this I think I have figured it out!
I'm seeing this on the debian log:
```
Setting up r-cran-lubridate (1.8.0+dfsg-1+b1) ..
```
Meaning that Debian is installing a version of lubridate that is technically out of date now, as lubridate 1.9.0 landed on CRAN 2 days ago (I assume CRAN is also installing an outdated version).
If you run my lubridate reprex from above with:
- rocker/r-base image with released R 4.2.2 (2022-10-31)
- lubridate 1.8.0
then you get:
```
library(lubridate)
i <- as.Date("2019-01-30") + months(-3:0)
i + months(1)
#> [1] "2018-11-30" "2018-12-30" "2019-01-30" "1970-01-30"
```
which clearly isn't right in that 4th slot, it should be `NA`.
This has to do with this R-devel bug which I thought was fixed before 4.2.2 went out? But it seems like I can reproduce this in R 4.2.2 which makes me think somehow it slipped through:
```
x <- as.POSIXlt(c("2019-01-30", "2019-01-31"), tz = "UTC")
x
#> [1] "2019-01-30 UTC" "2019-01-31 UTC"
# Looks like NA in the 2nd slot
x$mon <- c(0L, NA)
x
#> [1] "2019-01-30 UTC" NA
# But this borks it completely!
as.Date(x)
#> [1] "2019-01-30" "1970-01-01"
```
I can't reproduce this in R-devel 2022-11-07 r83308, the `as.Date()` call there correctly gives me `NA` in the 2nd slot.
lubridate happened to switch to using timechange as a backend in the last release, and it probably changes the internal code in such a way that it now happens to avoid this bug, which is why we don't see it on R 4.2.2 with lubridate 1.9.0.
So I think CRAN and Debian just need to rerun these checks with lubridate 1.9.0, and in the meantime I will go ahead and send in a patch release of slider to fix the strict-prototype warnings.
-Davis