I have tweaked the selection of this in R-devel.
For a long time the handling of timedates in macOS was 32-bit, and that
included the zoneinfo compiler (/usr/sbin/zic) and hence the shipped
timezone database. The latter is now 64-bit on High Sierra (the earliest
we support) but there must still be 32-bit aspects to the system code as
it fails sanity checks outside 1902-2037.
This means we now have the choice of using the system database or the
one installed into R and the R-devel now uses whichever version is later.
IANA update the database a few times a year (5x in 2018, 3x in 2019,
once so far in 2020). We update the R sources fairly quickly, but
released versions and installed R do not get updated. AFAICS Apple
updates the system version as part of security updates, so a few times a
year for still-supported versions -- High Sierra is up-to-date at
April's version 2020a.
For most people this hardly matters as time zone changes get a lot of
notice -- but not e.g. for Morocco over Ramadan (a reason for the 2020a
update). However, that may well change as the EU has agreed to outlaw
DST transitions from 2021 and leave to the states whether they stay on
summer time or make one last change in Oct 2021. (Some neighbouring
states are likely to follow suit, but not the UK which matters on the
island of Ireland.) Which means we do not currently know what timezones
in Europe will be in 2021. We can be pretty sure Apple will update the
macOS databases once this is decided, but users of R 4.0.last will not
get updates from us.
There should be no change in behaviour until there is a macOS system
database later than that installed in R, which for up-to-date R-devel is
unlikely.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
