timestamps on CRAN incoming might not be reliable?

[Ben Bolker]

Now that I've added timestamps to cran_incoming(), I'm wondering how reliable they are for answering the question I thought they answered (when a package entered a specified folder/category). For a particular submission I'm tracking, it looks like the time stamp stayed the same when the file left recheck and entered pending ...

I don't think this is a big deal, just wanted to note the issue. Ideally someone with lots of time on their hands would do some experiments and figure out what the actual behaviour is, then add it to the documentation ...

[Kirill Müller]

Right now they're also a year off:

foghorn::cran_incoming()
#> # A tibble: 121 x 5
#>    package          version    cran_folder time                   size
#>    <chr>            <pckg_vrs> <chr>       <dttm>                <int>
#>  1 libproj          7.1.0.3    pending     2021-10-14 15:48:00 4614430
#>  2 Matrix           1.3.1      waiting     2021-12-23 14:50:00 1927099
#>  3 phangorn         2.6.1      waiting     2021-12-17 21:31:00 1914991
#>  4 slackr           2.0.1      waiting     2021-12-16 02:03:00   16906
#>  5 ActivityIndex    0.3.7      archive     2021-12-17 18:49:00 4284772
#>  6 AnchorRegression 0.1.1      archive     2021-12-10 07:46:00    3399
#>  7 AnchorRegression 0.1.2      archive     2021-12-10 11:50:00    3331
#>  8 BANOVA           1.1.9      archive     2021-12-17 18:30:00  169684
#>  9 BED              1.4.2      archive     2021-12-12 16:34:00  649024
#> 10 BTYDplus         1.2.0      archive     2021-12-14 14:56:00  497407
#> # … with 111 more rows

^{Created on 2021-01-04 by the reprex package (v0.3.0)}

[François Michonneau]

thanks for reporting this, I "fixed" it.

Looking into it, it seems that curl doesn't report the year of the files that are less than 6 months old. The year was hardcoded to the current year. I hacked a workaround for the time being to check whether the date is in the future, but a couple of issues remain:

• when the year will be returned it won't be parsed correctly (I haven't seen it yet and it's rare for old files to linger around the server to implement this)
• the original issue brought up by Ben most likely remains.