Greg, If the problem is in your local checks you can add _R_CHECK_SYSTEM_CLOCK_=FALSE to your .Renviron to omit that check. See R internals (which documents CRAN's default too) [1].
Best, Lluís [1]: https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#index-_005fR_005fCHECK_005fSYSTEM_005fCLOCK_005f On Fri, 1 Aug 2025 at 00:41, Simon Urbanek <simon.urba...@r-project.org> wrote: > 1) R has no native NTP client > 2) outside NTP access is very often blocked on local networks (and local > NTP relay requires configuration for which there is no standard) > 3) it is overkill as we don’t need microsecond accuracy so a single > HTTP(s) request is much easier > > > > On 1/08/2025, at 10:17, Greg Hunt <g...@firmansyah.com> wrote: > > > > I noticed recently that check --as-cran was hanging and then emitting a > message about not being able to verify the current time. It seems that the > CRAN check code is using some website to get the current clock time and > that that site is currently down. This strikes me as an odd approach to > getting the current time. Why was that approach taken when NTP is > available on all mainstream OSs? Is there something unusual about the > CRAN environment? > > > > Greg > > > > [[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 > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
