Re: CRAN package slider

One last thing. I have confirmed that this was a bug that was introduced in R 4.2.2, but has since been patched in R-devel.

Is that something that can be fixed in R 4.2.2 Patched (I'm not sure how that works)?

```
x <- as.POSIXlt(c("2019-01-30", "2019-01-31"), tz = "UTC")
x
#> [1] "2019-01-30 UTC" "2019-01-31 UTC"

# Make the 2nd element NA by setting one of the fields to NA
x$mon <- c(0L, NA)
x
#> [1] "2019-01-30 UTC" NA

# R 4.2.1
as.Date(x)
#> [1] "2019-01-30" NA

# R 4.2.2
as.Date(x)
#> [1] "2019-01-30" "1970-01-01"

# R-devel, 2022-11-07 r83308
as.Date(x)
#> [1] "2019-01-30" NA
```

This has practical implications for lubridate users that update to R 4.2.2 but stay on lubridate 1.8.0, as this code no longer works. Luckily we can tell users to just update to lubridate 1.9.0 if they have issues, which works on all the R versions in question:

```
library(lubridate)

i <- as.Date("2019-01-30")
i
#> [1] "2019-01-30"

# R 4.2.2, lubridate 1.8.0
i + months(1)
#> [1] "1970-01-30"

# R 4.2.2, lubridate 1.9.0 (the NA is correct behavior)
i + months(1)
#> [1] NA
```

Thanks all,

Davis

On Tue, Nov 8, 2022 at 6:04 PM Davis Vaughan <davis@posit.co> wrote:

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

On Tue, Nov 8, 2022 at 5:30 PM Davis Vaughan <davis@posit.co> wrote:
Hi all,

I fixed the strict-prototypes warnings here https://github.com/DavisVaughan/slider/pull/175
(BTW, did you see Lionel's message about this on r-package-devel? https://stat.ethz.ch/pipermail/r-package-devel/2022q4/008589.html)

I have slider ready to go, but can't reproduce the issues seen on the CRAN machines and on the Debian autopkgtest. I've tried a number of things, including:

- Using the rocker/r-base image with released R 4.2.2 (2022-10-31), where I tried to run tests on the slider_0.2.2.tar.gz downloaded from CRAN with R CMD check and on the actual source code of slider pulled from GitHub with devtools::check()
- Submitting slider to win-devel, where it comes back clean
- Checking it locally on my own Mac, of course, with various versions of R including the exact r83217 revision it seems to be failing with on CRAN

Those tests should have errored earlier in `check_endpoints_cannot_be_na()` where a missing value check is run, but somehow it is bypassed and is then erroring on the next check, which checks that all values are in ascending order. So my guess is that it has something to do with lubridate and this month addition, which should always result in a missing value in the 4th element, but that must not be the case somehow (here are the expected results):

```
library(lubridate)
i <- as.Date("2019-01-30") + months(-3:0)
i + months(1)
#> [1] "2018-11-30" "2018-12-30" "2019-01-30" NA
```

If anyone can reproduce the test failures themselves, I'd be grateful if you could help me figure out what I might be missing here. I'm very motivated to try and get this fixed for CRAN.

-Davis

On Tue, Nov 8, 2022 at 6:30 AM Kurt Hornik <Kurt.Hornik@wu.ac.at> wrote:
Davis,

Please see

<https://cran.r-project.org/web/checks/check_results_slider.html>

Unfortunately, in addition to the new strict-prototypes compilation
warnings in r-devel we also have test ERRORs for the Debian r-patched
and r-release checks, which also materialize in the autopkgtest checks
for the r-cran-slider package and thus currently prevent the migration
of the new R 4.2.2 Debian packages from unstable to testing, see

<https://tracker.debian.org/pkg/r-base>

My hope is that this can be overridden quickly to get the Debian
packages migrated to testing, but in any case, can you please fix the
ERRORs (and ideally also the compilation warnings) as quickly as
possible?

Best
-k