Simon,
I have been down a bit of a rabbit hole with this. There is an interesting
APNIC blog entry related to this that tries to quantify the distribution of
clock skews.
1. I have a very simple R NTP client. It does not implement the server
clock time adjustment process bits of the protocol, but at a point in time
its able to detect and discard unsynchronised servers and outlier
responses. You can have it if you want, but I think its the answer to the
wrong question.
3. The webservers that the check code references go down periodically, one
is unresponsive from here this afternoon. I agree you don't need
microseconds or even tens of milliseconds, the check code allows for five
minutes of drift which is consistent with Kerberos tolerance of time
mismatches, but you do need "up" and "up" is not reliably there. The www.
or cran.r-project.org servers respond to a GET with a standard HTTP Date
header that contains that server's current idea of what the time is (you
can see it using curlGetHeaders("http://cran.r-project.org";), the timezone
is required by the HTTP standard to always be GMT/UTC) and I assume the
core team have some level of control over those servers' configurations and
should be easily able to ensure time synchronisation with some sufficiently
reliable time source if that time sync is not already in place. I suspect
that cran.r-project.org is more reliable than the websites you are using
as time sources.
Wouldn't it be possible to use an r-project server, as described above, as
a time source?
Greg
On Fri, 1 Aug 2025 at 08: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
> >
>
>
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
