Does all this mean that the check is not handling its own errors? On Sat, 8 Feb 2025 at 8:28 AM, Henrik Bengtsson <henrik.bengts...@gmail.com> wrote:
> > It has to have the "datetime" entry. If you can't fix your network you > can skip that test with > > > > _R_CHECK_FUTURE_FILE_TIMESTAMPS_=FALSE > > I'm quite sure that is overridden 'R CMD check' when using the > --as-cran flag. The workaround that I have found is to set environment > variable: > > _R_CHECK_SYSTEM_CLOCK_=FALSE > > I have observed <http://worldtimeapi.org/api/timezone/etc/UTC> timing > out a lot over the last couple of months from several different > networks and hosts. I've seen it happen in the past too (last couple > of years), but it has got considerably worse recently. Maybe they're > throttling in per IP(?). I consider it quite unreliable these days, so > I use _R_CHECK_SYSTEM_CLOCK_=FALSE by default now. > > /Henrik > > On Tue, Feb 4, 2025 at 5:50 PM Simon Urbanek > <simon.urba...@r-project.org> wrote: > > > > Josiah, > > > > that test tests the accuracy of the system clock by querying > https://worldtimeapi.org/api/timezone/etc/UTC so my guess would be that > you have either network or proxy issues which cause that request to fail by > providing garbage instead of the actual response. > > > > The call to test yourself is > > > readLines("http://worldtimeapi.org/api/timezone/etc/UTC";, warn=FALSE) > > [1] > "{\"utc_offset\":\"+00:00\",\"timezone\":\"Etc/UTC\",\"day_of_week\":3,\"day_of_year\":36,\"datetime\":\"2025-02-05T01:42:19.272728+00:00\",\"utc_datetime\":\"2025-02-05T01:42:19.272728+00:00\",\"unixtime\":1738719739,\"raw_offset\":0,\"week_number\":6,\"dst\":false,\"abbreviation\":\"UTC\",\"dst_offset\":0,\"dst_from\":null,\"dst_until\":null,\"client_ip\":\"121.98.39.155\"}" > > > > It has to have the "datetime" entry. If you can't fix your network you > can skip that test with > > > > _R_CHECK_FUTURE_FILE_TIMESTAMPS_=FALSE > > > > Cheers, > > Simon > > > > > > > On Feb 5, 2025, at 10:11 AM, Josiah Parry <josiah.pa...@gmail.com> > wrote: > > > > > > I'm running R CMD check for my package {calcite} (source: > > > https://github.com/r-arcGIS/calcite) which is failing due to what > *looks* like > > > a bug. > > > > > > R CMD check fails at "checking for future file timestamps" > > > > > > I get this error: ...Error in if (abs(unclass(now_local) - > > > unclass(now)[1]) > 300) missing value where TRUE/FALSE needed. > > > > > > It seems that an NA is being generated somehow during this check but > I'm > > > unsure how. > > > > > > One thing that comes to mind is that the file that contains all of my > > > function definitions is generated using writeLines() but the output of > ` > > > file.info()` looks normal to me. > > > > > > Have others encountered this? I'm on R 4.4.0 Puppy Cup > > > > > > platform aarch64-apple-darwin20 > > > arch aarch64 > > > os darwin20 > > > system aarch64, darwin20 > > > status > > > major 4 > > > minor 4.0 > > > year 2024 > > > month 04 > > > day 24 > > > svn rev 86474 > > > language R > > > version.string R version 4.4.0 (2024-04-24) > > > nickname Puppy Cup > > > > > > [[alternative HTML version deleted]] > > > > > > ______________________________________________ > > > R-package-devel@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > > > > ______________________________________________ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
