Add SA-18:04.vt, SA-18:05.ipsec, EN-18:03.tzdata, EN-18:04.mem.

Approved by: so
author: Gordon Tetlow <gordon@FreeBSD.org> 2018-04-04 05:55:14 +0000
committer: Gordon Tetlow <gordon@FreeBSD.org> 2018-04-04 05:55:14 +0000
commit: 866286679f1bffc2426cee5e9350f7596dc297d9 (patch)
tree: 2db9ce4a7407a6cf02f45ec66dc5db541da68f6c /share
parent: 009a15ab0b8b2f059e1adc8c99d4663d624c2600 (diff)
14 files changed, 5479 insertions, 0 deletions
diff --git a/share/security/advisories/FreeBSD-EN-18:03.tzdata.asc b/share/security/advisories/FreeBSD-EN-18:03.tzdata.asc
new file mode 100644
index 0000000000..e750930af0
--- /dev/null
+++ b/share/security/advisories/FreeBSD-EN-18:03.tzdata.asc
@@ -0,0 +1,149 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA512
+
+=============================================================================
+FreeBSD-EN-18:03.tzdata                                         Errata Notice
+                                                          The FreeBSD Project
+
+Topic:          Timezone database information update
+
+Category:       contrib
+Module:         zoneinfo
+Announced:      2018-04-04
+Credits:        Philip Paeps
+Affects:        All supported versions of FreeBSD
+Corrected:      2018-03-28 07:42:50 UTC (stable/11, 11.1-STABLE)
+                2018-04-04 05:40:48 UTC (releng/11.1, 11.1-RELEASE-p9)
+                2018-03-28 07:45:57 UTC (stable/10, 10.4-STABLE)
+                2018-04-04 05:40:48 UTC (releng/10.4, 10.4-RELEASE-p8)
+                2018-04-04 05:40:48 UTC (releng/10.3, 10.3-RELEASE-p29)
+
+For general information regarding FreeBSD Errata Notices and Security
+Advisories, including descriptions of the fields above, security
+branches, and the following sections, please visit
+<URL:https://security.FreeBSD.org/>.
+
+I.   Background
+
+The tzsetup(8) program allows the user to specify the default local timezone.
+Based on the selected timezone, tzsetup(8) copies one of the files from
+/usr/share/zoneinfo to /etc/localtime.  This file actually controls the
+conversion.
+
+II.  Problem Description
+
+Several changes in Daylight Savings Time happened after previous FreeBSD
+releases were released that would affect many people who live in different
+countries.  Because of these changes, the data in the zoneinfo files need to
+be updated, and if the local timezone on the running system is affected,
+tzsetup(8) needs to be run so the /etc/localtime is updated.
+
+III. Impact
+
+An incorrect time will be displayed on a system configured to use one of the
+affected timezones if the /usr/share/zoneinfo and /etc/localtime files are
+not updated, and all applications on the system that rely on the system time,
+such as cron(8) and syslog(8), will be affected.
+
+IV.  Workaround
+
+The system administrator can install an updated timezone database from the
+misc/zoneinfo port and run tzsetup(8) to get the timezone database corrected.
+
+Applications that store and display times in Coordinated Universal Time (UTC)
+are not affected.
+
+V.   Solution
+
+Please note that some third party software, for instance PHP, Ruby, Java and
+Perl, may be using different zoneinfo data source, in such cases this
+software must be updated separately.  For software packages that is installed
+via binary packages, they can be upgraded by executing `pkg upgrade'.
+
+Following the instructions in this Errata Notice will update all of the
+zoneinfo files to be the same as what was released with FreeBSD release.
+
+Perform one of the following:
+
+1) Upgrade your system to a supported FreeBSD stable or release / security
+branch (releng) dated after the correction date. Restart all the affected
+applications and daemons, or reboot the system.
+
+2) To update your system via a binary patch:
+
+Systems running a RELEASE version of FreeBSD on the i386 or amd64
+platforms can be updated via the freebsd-update(8) utility:
+
+# freebsd-update fetch
+# freebsd-update install
+
+Restart all the affected applications and daemons, or reboot the system.
+
+3) To update your system via a source code patch:
+
+The following patches have been verified to apply to the applicable
+FreeBSD release branches.
+
+a) Download the relevant patch from the location below, and verify the
+detached PGP signature using your PGP utility.
+
+# fetch https://security.FreeBSD.org/patches/EN-18:03/tzdata-2018d.patch
+# fetch https://security.FreeBSD.org/patches/EN-18:03/tzdata-2018d.patch.asc
+# gpg --verify tzdata-2018d.patch.asc
+
+b) Apply the patch.  Execute the following commands as root:
+
+# cd /usr/src
+# patch < /path/to/patch
+
+c) Recompile the operating system using buildworld and installworld as
+described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>.
+
+Restart all the affected applications and daemons, or reboot the system.
+
+VI.  Correction details
+
+The following list contains the correction revision numbers for each
+affected branch.
+
+Branch/path                                                      Revision
+- -------------------------------------------------------------------------
+stable/10/                                                        r331663
+releng/10.3/                                                      r331986
+releng/10.4/                                                      r331986
+stable/11/                                                        r331662
+releng/11.1/                                                      r331986
+- -------------------------------------------------------------------------
+
+To see which files were modified by a particular revision, run the
+following command, replacing NNNNNN with the revision number, on a
+machine with Subversion installed:
+
+# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
+
+Or visit the following URL, replacing NNNNNN with the revision number:
+
+<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
+
+VII. References
+
+The latest revision of this advisory is available at
+<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-18:03.tzdata.asc>
+-----BEGIN PGP SIGNATURE-----
+
+iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlrEZutfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
+MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
+5cKJ7A/+NXjXPibYne7thcIjSJPFJDlA13Ga4UhKytjO7KW2wN5CjQp62ULwCfaO
+dcl5ysljMGXxNmCBqCcfQrO9AL7vnOxQSr60KwB8AAzIBPfLzXrqopXW2fB/8pKP
+cOTJHpZlNQ4P8cJ1OHpjsovcA5a/7KQ87BgRj8AUJoeTlCPoLlDlnyCR6VMOswSa
+a8PX9cAb+lcQWGg56E+n7ZE0JEMDHUVwvHplU1m5nn1Dn8b04na+tn3MRMKi2iqF
+Y9MhLavfY1UzwXkuUKf/ODTuGSYF8Sy4lJgLrqs4awJXErIJvJNbh6V4h8uRpEIY
+iUN+wPBWsvfZ4X0KSb+4aPI5jpKnE2LATHiz2vDYuDZ5U5y9ec8GMuGnFOueNwcb
+vMQkPPPOj7VTTKUZPHgAGdYlsO9mLTMkAjiTPwB0kZ6P7MN0211dHN+fvr8Skwyl
+x9IFVW6h9XtTvSqU29/Nd3KSFORuiKowokxWTQ+jnEdsYCsm0wQNKH6avxedbEAA
+oKowh4zfTGO2jOzcuCtfmZNUFUAVYE0SASnYD4rxEDcuJNx/jSVhf1wY97G22s7n
+aLKDnHHGKHsLzQAuFEITaC0pMTs41XL1baO9RtjtZDSz/dKla+ZsgQk5yVKyR2v7
+tW6ertUBZiUfD50d0GKPgGEMTWH9k5a5hJvMhAMLfHzhxBT0B+w=
+=k+2X
+-----END PGP SIGNATURE-----
diff --git a/share/security/advisories/FreeBSD-EN-18:04.mem.asc b/share/security/advisories/FreeBSD-EN-18:04.mem.asc
new file mode 100644
index 0000000000..2fa2b02580
--- /dev/null
+++ b/share/security/advisories/FreeBSD-EN-18:04.mem.asc
@@ -0,0 +1,151 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA512
+
+=============================================================================
+FreeBSD-EN-18:04.mem                                            Errata Notice
+                                                          The FreeBSD Project
+
+Topic:          Multiple small kernel memory disclosures
+
+Category:       core
+Module:         kernel
+Announced:      2018-04-04
+Credits:        Ilja van Sprundel
+Affects:        All supported versions of FreeBSD.
+Corrected:      2018-03-28 13:41:43 UTC (stable/11, 11.1-STABLE)
+                2018-04-04 05:43:03 UTC (releng/11.1, 11.1-RELEASE-p9)
+                2018-03-29 22:31:14 UTC (stable/10, 10.4-STABLE)
+                2018-04-04 05:43:03 UTC (releng/10.4, 10.4-RELEASE-p8)
+                2018-04-04 05:43:03 UTC (releng/10.3, 10.3-RELEASE-p29)
+CVE Name:       CVE-2018-6919
+
+For general information regarding FreeBSD Errata Notices and Security
+Advisories, including descriptions of the fields above, security
+branches, and the following sections, please visit
+<URL:https://security.FreeBSD.org/>.
+
+I.   Background
+
+FreeBSD includes drivers for HighPoint disk controllers via the hpt27xx(4),
+hptnr(4) and hptrr(4) drivers, for some graphics cards via drm drivers.  In
+addition, FreeBSD includes optional support for executing svr4 and ibcs2
+binaries.
+
+II.  Problem Description
+
+Due to insufficient initialization of memory copied to userland small amounts
+of kernel memory may be disclosed to userland processes.
+
+III. Impact
+
+A user who can access these drivers or execute svr4 or ibcs2 binaries
+may be able to read the contents of kernel memory.
+
+Such memory might contain sensitive information, such as portions of the file
+cache or terminal buffers.  This information might be directly useful, or it
+might be leveraged to obtain elevated privileges in some way; for example,
+a terminal buffer might include a user-entered password.
+
+IV.  Workaround
+
+No workaround is available, but systems that do not use these devices and
+do not enable support for ibcs2 and svr4 binaries are not vulnerable.
+In addition, note that the drm driver affected by this issue supports only
+relatively old hardware.  Systems built within the last decade likely
+contain graphics hardware supported by the drm2 driver in the FreeBSD base
+system or the drm-next-kmod driver in FreeBSD ports.
+
+V.   Solution
+
+Perform one of the following:
+
+1) Upgrade your system to a supported FreeBSD stable or release / security
+branch (releng) dated after the correction date.
+
+Afterward, reboot the system.
+
+2) To update your system via a binary patch:
+
+Systems running a RELEASE version of FreeBSD on the i386 or amd64
+platforms can be updated via the freebsd-update(8) utility:
+
+# freebsd-update fetch
+# freebsd-update install
+
+Afterward, reboot the system.
+
+3) To update your system via a source code patch:
+
+The following patches have been verified to apply to the applicable
+FreeBSD release branches.
+
+a) Download the relevant patch from the location below, and verify the
+detached PGP signature using your PGP utility.
+
+[FreeBSD 11.x]
+# fetch https://security.FreeBSD.org/patches/EN-18:04/mem.11.patch
+# fetch https://security.FreeBSD.org/patches/EN-18:04/mem.11.patch.asc
+# gpg --verify mem.11.patch.asc
+
+[FreeBSD 10.x]
+# fetch https://security.FreeBSD.org/patches/EN-18:04/mem.10.patch
+# fetch https://security.FreeBSD.org/patches/EN-18:04/mem.10.patch.asc
+# gpg --verify mem.10.patch.asc
+
+b) Apply the patch.  Execute the following commands as root:
+
+# cd /usr/src
+# patch < /path/to/patch
+
+c) Recompile your kernel as described in
+<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
+system.
+
+VI.  Correction details
+
+The following list contains the correction revision numbers for each
+affected branch.
+
+Branch/path                                                      Revision
+- -------------------------------------------------------------------------
+stable/10/                                                        r331749
+releng/10.3/                                                      r331987
+releng/10.4/                                                      r331987
+stable/11/                                                        r331670
+releng/11.1/                                                      r331987
+- -------------------------------------------------------------------------
+
+To see which files were modified by a particular revision, run the
+following command, replacing NNNNNN with the revision number, on a
+machine with Subversion installed:
+
+# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
+
+Or visit the following URL, replacing NNNNNN with the revision number:
+
+<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
+
+VII. References
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6919>
+
+The latest revision of this advisory is available at
+<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-18:04.mem.asc>
+-----BEGIN PGP SIGNATURE-----
+
+iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlrEZvNfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
+MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
+5cJa/A//Z53qYxwSpKH5hrkHsMVzH62xagHUn7zqewyfmBIaz8xLPArNYEy3onPv
+5mXLLL5RIoaiUXq++Nld90QPDbbHtuyfwKySm/X8vNXUu/a2mFpzSixI1tQEIcsx
+PH+eqCQTgFHyzo0uADRcLyxuo4qmM/b/8LQZWr0CLpxmdPVuoGG2tlcVpL47f5sa
+nFghwxiOj5gKCR0Wx0buZ8u1T0NV0EyGcI7SRXJItq1GM8lvb26bfSnDls5h0hPW
+dn8qa7+exYL133qZ4vgEyNk+cGjEGNIG1eoAe3WeoUaaFsmpXTNK17P8Gxr/KZk4
+QmMiRbbIooX4AsNnY+OnkGRN1LzxFF2TLc+zYGV7j/uyhGE5cfZ3Av3hDMFlyTRO
+Udp1/ghmm/GPrHO/FAmJGYPmfxRYdU/jZU6gJld+QXd2y8/HLsXNOdRK92KIwCyp
+I9tUVwMg4mze6L6/s1chmQL5jdy5Sz5SSfjDAcP3ieJ5cmg0DDITYjWEVk4Fdaxl
+rWU2X2nYmJeROqU6tlAEfMPJZEw2cPxE14vRe3iN9mPUSPvGKT4oWLMtwRnjsQyz
+v8da9m4lncTQd5/qz9BpWzFANP6+g8gmgm8G4j1HeVyf2WFPMsU+YqAoaQewB3h5
+Hnfq/GhTTNtvjTnW2trPT21lXPEFbuVVZ724U+SJwYzVJv2tyug=
+=r842
+-----END PGP SIGNATURE-----
diff --git a/share/security/advisories/FreeBSD-SA-18:04.vt.asc b/share/security/advisories/FreeBSD-SA-18:04.vt.asc
new file mode 100644
index 0000000000..520bfff2fe
--- /dev/null
+++ b/share/security/advisories/FreeBSD-SA-18:04.vt.asc
@@ -0,0 +1,140 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA512
+
+=============================================================================
+FreeBSD-SA-18:04.vt                                         Security Advisory
+                                                          The FreeBSD Project
+
+Topic:          vt console memory disclosure
+
+Category:       core
+Module:         vt console
+Announced:      2018-04-04
+Credits:        Dr Silvio Cesare of InfoSect
+Affects:        All supported versions of FreeBSD.
+Corrected:      2018-04-04 05:24:59 UTC (stable/11, 11.1-STABLE)
+                2018-04-04 05:33:56 UTC (releng/11.1, 11.1-RELEASE-p9)
+                2018-04-04 05:26:33 UTC (stable/10, 10.4-STABLE)
+                2018-04-04 05:33:56 UTC (releng/10.4, 10.4-RELEASE-p8)
+                2018-04-04 05:33:56 UTC (releng/10.3, 10.3-RELEASE-p29)
+CVE Name:       CVE-2018-6917
+
+For general information regarding FreeBSD Security Advisories,
+including descriptions of the fields above, security branches, and the
+following sections, please visit <URL:https://security.FreeBSD.org/>.
+
+I.   Background
+
+On FreeBSD 11 and later, and FreeBSD 10.x systems that boot via UEFI, the
+default system video console is provided by the vt(4) driver.  The console
+allows the user, including an unprivileged user, to load a font at runtime.
+
+II.  Problem Description
+
+Insufficient validation of user-provided font parameters can result in an
+integer overflow, leading to the use of arbitrary kernel memory as glyph
+data.  Characters that reference this data can be displayed on the screen,
+effectively disclosing kernel memory.
+
+III. Impact
+
+Unprivileged users may be able to access privileged kernel data.
+
+Such memory might contain sensitive information, such as portions of the file
+cache or terminal buffers.  This information might be directly useful, or it
+might be leveraged to obtain elevated privileges in some way; for example,
+a terminal buffer might include a user-entered password.
+
+IV.  Workaround
+
+The syscons sc(4) system console is not affected by this issue and may be
+used on systems that do not boot via UEFI.  To use the syscons console,
+set the kern.vty tunable in /boot/loader.conf as described in sc(4), and
+reboot.  No workaround is available for systems that boot via UEFI.
+
+V.   Solution
+
+Perform one of the following:
+
+1) Upgrade your vulnerable system to a supported FreeBSD stable or
+release / security branch (releng) dated after the correction date.
+
+2) To update your vulnerable system via a binary patch:
+
+Systems running a RELEASE version of FreeBSD on the i386 or amd64
+platforms can be updated via the freebsd-update(8) utility:
+
+# freebsd-update fetch
+# freebsd-update install
+
+A reboot is required after the upgrade.
+
+3) To update your vulnerable system via a source code patch:
+
+The following patches have been verified to apply to the applicable
+FreeBSD release branches.
+
+a) Download the relevant patch from the location below, and verify the
+detached PGP signature using your PGP utility.
+
+# fetch https://security.FreeBSD.org/patches/SA-18:04/vt.patch
+# fetch https://security.FreeBSD.org/patches/SA-18:04/vt.patch.asc
+# gpg --verify vt.patch.asc
+
+b) Apply the patch.  Execute the following commands as root:
+
+# cd /usr/src
+# patch < /path/to/patch
+
+c) Recompile your kernel as described in
+<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
+system.
+
+VI.  Correction details
+
+The following list contains the correction revision numbers for each
+affected branch.
+
+Branch/path                                                      Revision
+- -------------------------------------------------------------------------
+stable/10/                                                        r331983
+releng/10.3/                                                      r331984
+releng/10.4/                                                      r331984
+stable/11/                                                        r331982
+releng/11.1/                                                      r331984
+- -------------------------------------------------------------------------
+
+To see which files were modified by a particular revision, run the
+following command, replacing NNNNNN with the revision number, on a
+machine with Subversion installed:
+
+# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
+
+Or visit the following URL, replacing NNNNNN with the revision number:
+
+<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
+
+VII. References
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6917>
+
+The latest revision of this advisory is available at
+<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-18:04.vt.asc>
+-----BEGIN PGP SIGNATURE-----
+
+iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlrEZttfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
+MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
+5cI5CBAAmZS+2l3qNafZ0FQDKONeX+jiyJt6lPWk2LUd/jJXnEnVjqiP/pW1YpC0
+9oob5gFaCt8YEpQRIPGU1VwIfX16KeMSiM2TYnZXAaTzSo5ecWemrQ706ds7hy+m
+FmlyoqoqmDn3AyziTeJAxFc2QVZ5jo25KWZL7zMJdNjGqzFao4UktY01Sy9fB3Ak
+rgi/AInZV1FGt1KrH04zJpK+WSfNtM553e7KfFlmD6cR+yXViHfGHl6TBYcb1H3y
+8wjfZmdlfyFMB84bQ5bw9iqx5fHhth4s/0sbAErRAS/PeWOKF9uxSVy3t4p160BZ
+Ym7k4PXYO8hUH9n5mqDzg/asPkRA8nJMqmUtvBJrdUMi9VhQqOybhddZNAZp7RGb
+6BtlsBUaRRmxA9tm4h5nbk+Fy9/qqtkcOdsJNqqAdSk4nTTkkkKPNPrIkXKcW4HE
+qv8c71xDkpbAGfQjkC2B4VXg9uoQIi36F8843ha6UbhdL2urSWWPXLBOoSupRAyp
+PkB35tvulXyJ/cRRf/FfAL+lSmoqImi2WjSjpd+fqABWSaxrypJqI0Cca3ySdhVG
+mylVk2sDW/d27Wltyd1Pdy9qXHVSEoKwdWemCamAABFwaCf49D1xrgysCrdY+uFp
+zydy8rxJ0Bht18n4Yhp+WveujRFwamvGjWxYbxJ0g+LD+SWD7Zs=
+=L6/K
+-----END PGP SIGNATURE-----
diff --git a/share/security/advisories/FreeBSD-SA-18:05.ipsec.asc b/share/security/advisories/FreeBSD-SA-18:05.ipsec.asc
new file mode 100644
index 0000000000..e2f6f9e15e
--- /dev/null
+++ b/share/security/advisories/FreeBSD-SA-18:05.ipsec.asc
@@ -0,0 +1,142 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA512
+
+=============================================================================
+FreeBSD-SA-18:05.ipsec                                      Security Advisory
+                                                          The FreeBSD Project
+
+Topic:          ipsec crash or denial of service
+
+Category:       core
+Module:         ipsec
+Announced:      2018-04-04
+Credits:        Maxime Villard
+Affects:        All supported versions of FreeBSD.
+Corrected:      2018-01-31 09:24:48 UTC (stable/11, 11.1-STABLE)
+                2018-04-04 05:37:52 UTC (releng/11.1, 11.1-RELEASE-p9)
+                2018-01-31 09:26:28 UTC (stable/10, 10.4-STABLE)
+                2018-04-04 05:37:52 UTC (releng/10.4, 10.4-RELEASE-p8)
+                2018-04-04 05:37:52 UTC (releng/10.3, 10.3-RELEASE-p29)
+CVE Name:       CVE-2018-6918
+
+For general information regarding FreeBSD Security Advisories,
+including descriptions of the fields above, security branches, and the
+following sections, please visit <URL:https://security.FreeBSD.org/>.
+
+I.   Background
+
+The IPsec suite of protocols provide network level security for IPv4 and IPv6
+packets.  FreeBSD includes software originally developed by the KAME project
+which implements the various protocols that make up IPsec.
+
+In IPsec, the IP Authentication Header (AH) is used to provide protection
+against replay attacks and connectionless integrity and data origin
+authentication for IP datagrams.
+
+II.  Problem Description
+
+The length field of the option header does not count the size of the option
+header itself.  This causes a problem when the length is zero, the count is
+then incremented by zero, which causes an infinite loop.
+
+In addition there are pointer/offset mistakes in the handling of IPv4
+options.
+
+III. Impact
+
+A remote attacker who is able to send an arbitrary packet, could cause the
+remote target machine to crash.
+
+IV.  Workaround
+
+No workaround is available.  Note that in FreeBSD 10 IPsec is not included
+in the kernel by default, but it is in FreeBSD 11.
+
+V.   Solution
+
+Perform one of the following:
+
+1) Upgrade your vulnerable system to a supported FreeBSD stable or
+release / security branch (releng) dated after the correction date.
+
+Afterward, reboot the system.
+
+2) To update your vulnerable system via a binary patch:
+
+Systems running a RELEASE version of FreeBSD on the i386 or amd64
+platforms can be updated via the freebsd-update(8) utility:
+
+# freebsd-update fetch
+# freebsd-update install
+
+Afterward, reboot the system.
+
+3) To update your vulnerable system via a source code patch:
+
+The following patches have been verified to apply to the applicable
+FreeBSD release branches.
+
+a) Download the relevant patch from the location below, and verify the
+detached PGP signature using your PGP utility.
+
+# fetch https://security.FreeBSD.org/patches/SA-18:05/ipsec.patch
+# fetch https://security.FreeBSD.org/patches/SA-18:05/ipsec.patch.asc
+# gpg --verify ipsec.patch.asc
+
+b) Apply the patch.  Execute the following commands as root:
+
+# cd /usr/src
+# patch < /path/to/patch
+
+c) Recompile your kernel as described in
+<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
+system.
+
+VI.  Correction details
+
+The following list contains the correction revision numbers for each
+affected branch.
+
+Branch/path                                                      Revision
+- -------------------------------------------------------------------------
+stable/10/                                                        r328621
+releng/10.3/                                                      r331985
+releng/10.4/                                                      r331985
+stable/11/                                                        r328620
+releng/11.1/                                                      r331985
+- -------------------------------------------------------------------------
+
+To see which files were modified by a particular revision, run the
+following command, replacing NNNNNN with the revision number, on a
+machine with Subversion installed:
+
+# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
+
+Or visit the following URL, replacing NNNNNN with the revision number:
+
+<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
+
+VII. References
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6918>
+
+The latest revision of this advisory is available at
+<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-18:05.ipsec.asc>
+-----BEGIN PGP SIGNATURE-----
+
+iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlrEZuRfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
+MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
+5cKpOxAAlcyr88qHimXmMWNelNe+RvNkRoQwlmOw5XCWmWFGt4bX6KyrPSNVkZXK
+9bZr0+sYiEjHPstXy+F6v95wqShRiefwpLVNJkP6LFKdQJeuxy0Uwsgl/i3aZVHy
+q4iM+PgnMwt5FxzmIcFHjwZSGGaOw5p9dMlkFLxXQ6chafPutMbgkXMIGVGXEp4e
+iwQgmh7j5LbUED0P9G7sYpcEN+DKZLWIyvz6L/AJmeHC/Z21TTeOoPjNPImgUmeU
+R2gK6WrQ5hfDvvFIJK1RvkR7OGdgrw0p2bCeeW8HRR5WEifO+a5Mb6+S414jWLYi
+uPYoxWf5NP92b9r3sLjNXbbsZ71mOZ49nZO3gc83O4mqOo9FYbTZ1W9C1UIO66pO
+bsp9e7g09gvT/VTO9j2Bu9nNdLd41Jx6NCmrrJAPP5fp7yhgtI7a+voF+swyBPSq
+kzSrNuY+PAnEvvAPzCz97uQQWabwbJoZNlPc+9IWZ7K++8N9j0K94dtsy8g6FMIT
+A54s3LX9X5v+EYEwqnbNgEZxkSgjgpQkbnQC3evBwVkSgm0aQb4jRXoe9aY6KGtA
+pSldkfyC364h8KNM1tbMq02fAIGDdBc+TbxjPabdc+FNmwVT+KlW/cBDy8J/rUhz
+BSyWQdVwjHZ45R4Vmf8pEDA4/uc/L7XnMuqwgn2gBe23riiAjDM=
+=WcBl
+-----END PGP SIGNATURE-----
diff --git a/share/security/patches/EN-18:03/tzdata-2018d.patch b/share/security/patches/EN-18:03/tzdata-2018d.patch
new file mode 100644
index 0000000000..1383dd91dd
--- /dev/null
+++ b/share/security/patches/EN-18:03/tzdata-2018d.patch
@@ -0,0 +1,4454 @@
+--- contrib/tzdata/CONTRIBUTING.orig
++++ contrib/tzdata/CONTRIBUTING
+@@ -25,7 +25,8 @@
+ 
+ Please submit changes against either the latest release in
+ <https://www.iana.org/time-zones> or the master branch of the development
+-repository.  If you use Git the following workflow may be helpful:
++repository.  The latter is preferred.  If you use Git the following
++workflow may be helpful:
+ 
+   * Copy the development repository.
+ 
+@@ -42,6 +43,12 @@
+ 
+       git checkout -b mybranch
+ 
++  * Sleuth by using 'git blame'.  For example, when fixing data for
++    Africa/Sao_Tome, if the command 'git blame africa' outputs a line
++    '2951fa3b (Paul Eggert 2018-01-08 09:03:13 -0800 1068) Zone
++    Africa/Sao_Tome 0:26:56 - LMT 1884', commit 2951fa3b should
++    provide some justification for the 'Zone Africa/Sao_Tome' line.
++
+   * Edit source files.  Include commentary that justifies the
+     changes by citing reliable sources.
+ 
+@@ -67,6 +74,9 @@
+ 
+       git send-email master
+ 
++    For an archived example of such an email, see
++    <https://mm.icann.org/pipermail/tz/2018-February/026122.html>.
++
+   * Start anew by getting current with the master branch again
+     (the second step above).
+ 
+--- contrib/tzdata/Makefile.orig
++++ contrib/tzdata/Makefile
+@@ -10,6 +10,15 @@
+ # Email address for bug reports.
+ BUGEMAIL=	tz@iana.org
+ 
++# Choose source data features.  To get new features right away, use:
++#	DATAFORM=	vanguard
++# To wait a while before using new features, to give downstream users
++# time to upgrade zic (the default), use:
++#	DATAFORM=	main
++# To wait even longer for new features, use:
++#	DATAFORM=	rearguard
++DATAFORM=		main
++
+ # Change the line below for your time zone (after finding the zone you want in
+ # the time zone files, or adding it to a time zone file).
+ # Alternately, if you discover you've got the wrong time zone, you can just
+@@ -25,10 +34,10 @@
+ # for handling POSIX-style time zone environment variables,
+ # change the line below (after finding the zone you want in the
+ # time zone files, or adding it to a time zone file).
+-# (When a POSIX-style environment variable is handled, the rules in the
++# When a POSIX-style environment variable is handled, the rules in the
+ # template file are used to determine "spring forward" and "fall back" days and
+ # times; the environment variable itself specifies UT offsets of standard and
+-# summer time.)
++# daylight saving time.
+ # Alternately, if you discover you've got the wrong time zone, you can just
+ #	zic -p rightzone
+ # to correct things.
+@@ -189,6 +198,7 @@
+ #  -DHAVE_STDINT_H if you have a non-C99 compiler with <stdint.h>
+ #  -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l
+ #  -DHAVE_STRDUP=0 if your system lacks the strdup function
++#  -DHAVE_STRTOLL=0 if your system lacks the strtoll function
+ #  -DHAVE_SYMLINK=0 if your system lacks the symlink function
+ #  -DHAVE_SYS_STAT_H=0 if your compiler lacks a <sys/stat.h>
+ #  -DHAVE_SYS_WAIT_H=0 if your compiler lacks a <sys/wait.h>
+@@ -195,7 +205,11 @@
+ #  -DHAVE_TZSET=0 if your system lacks a tzset function
+ #  -DHAVE_UNISTD_H=0 if your compiler lacks a <unistd.h>
+ #  -Dlocale_t=XXX if your system uses XXX instead of locale_t
++#  -DRESERVE_STD_EXT_IDS if your platform reserves standard identifiers
++#	with external linkage, e.g., applications cannot define 'localtime'.
+ #  -Dssize_t=long on hosts like MS-Windows that lack ssize_t
++#  -DSUPPRESS_TZDIR to not prepend TZDIR to file names; this has
++#	security implications and is not recommended for general use
+ #  -DTHREAD_SAFE to make localtime.c thread-safe, as POSIX requires;
+ #	not needed by the main-program tz code, which is single-threaded.
+ #	Append other compiler flags as needed, e.g., -pthread on GNU/Linux.
+@@ -394,13 +408,19 @@
+ SAFE_CHARSET=	$(SAFE_CHARSET1)$(SAFE_CHARSET2)$(SAFE_CHARSET3)
+ SAFE_CHAR=	'[]'$(SAFE_CHARSET)'-]'
+ 
++# Non-ASCII non-letters that OK_CHAR allows, as these characters are
++# useful in commentary.  XEmacs 21.5.34 displays them correctly,
++# presumably because they are Latin-1.
++UNUSUAL_OK_CHARSET= °±½¾×
++
+ # OK_CHAR matches any character allowed in the distributed files.
+-# This is the same as SAFE_CHAR, except that multibyte letters are
+-# also allowed so that commentary can contain people's names and quote
+-# non-English sources.  For non-letters the sources are limited to
+-# ASCII renderings for the convenience of maintainers whose text editors
+-# mishandle UTF-8 by default (e.g., XEmacs 21.4.22).
+-OK_CHAR=	'[][:alpha:]'$(SAFE_CHARSET)'-]'
++# This is the same as SAFE_CHAR, except that UNUSUAL_OK_CHARSET and
++# multibyte letters are also allowed so that commentary can contain a
++# few safe symbols and people's names and can quote non-English sources.
++# Other non-letters are limited to ASCII renderings for the
++# convenience of maintainers using XEmacs 21.5.34, which by default
++# mishandles Unicode characters U+0100 and greater.
++OK_CHAR=	'[][:alpha:]$(UNUSUAL_OK_CHARSET)'$(SAFE_CHARSET)'-]'
+ 
+ # SAFE_LINE matches a line of safe characters.
+ # SAFE_SHARP_LINE is similar, except any OK character can follow '#';
+@@ -462,10 +482,12 @@
+ ZONETABLES=	zone1970.tab zone.tab
+ TABDATA=	iso3166.tab $(TZDATA_TEXT) $(ZONETABLES)
+ LEAP_DEPS=	leapseconds.awk leap-seconds.list
+-TZDATA_ZI_DEPS=	zishrink.awk version $(TDATA) $(PACKRATDATA)
++TZDATA_ZI_DEPS=	ziguard.awk zishrink.awk version $(TDATA) $(PACKRATDATA)
++DSTDATA_ZI_DEPS= ziguard.awk $(TDATA) $(PACKRATDATA)
+ DATA=		$(TDATA_TO_CHECK) backzone iso3166.tab leap-seconds.list \
+ 			leapseconds yearistype.sh $(ZONETABLES)
+-AWK_SCRIPTS=	checklinks.awk checktab.awk leapseconds.awk zishrink.awk
++AWK_SCRIPTS=	checklinks.awk checktab.awk leapseconds.awk \
++			ziguard.awk zishrink.awk
+ MISC=		$(AWK_SCRIPTS) zoneinfo2tdf.pl
+ TZS_YEAR=	2050
+ TZS=		to$(TZS_YEAR).tzs
+@@ -499,7 +521,8 @@
+ 
+ SHELL=		/bin/sh
+ 
+-all:		tzselect yearistype zic zdump libtz.a $(TABDATA)
++all:		tzselect yearistype zic zdump libtz.a $(TABDATA) \
++		  vanguard.zi main.zi rearguard.zi
+ 
+ ALL:		all date $(ENCHILADA)
+ 
+@@ -534,11 +557,15 @@
+ 		printf '%s\n' "$$V" >$@.out
+ 		mv $@.out $@
+ 
+-# This file can be tailored by setting BACKWARD, PACKRATDATA, etc.
+-tzdata.zi:	$(TZDATA_ZI_DEPS)
++# These files can be tailored by setting BACKWARD, PACKRATDATA, etc.
++vanguard.zi main.zi rearguard.zi: $(DSTDATA_ZI_DEPS)
++		$(AWK) -v outfile='$@' -f ziguard.awk $(TDATA) $(PACKRATDATA) \
++		  >$@.out
++		mv $@.out $@
++tzdata.zi:	$(DATAFORM).zi version
+ 		version=`sed 1q version` && \
+ 		  LC_ALL=C $(AWK) -v version="$$version" -f zishrink.awk \
+-		    $(TDATA) $(PACKRATDATA) >$@.out
++		    $(DATAFORM).zi >$@.out
+ 		mv $@.out $@
+ 
+ version.h:	version
+@@ -614,19 +641,29 @@
+ 
+ zones:		$(REDO)
+ 
++# dummy.zd is not a real file; it is mentioned here only so that the
++# top-level 'make' does not have a syntax error.
++ZDS = dummy.zd
++# Rule used only by submakes invoked by the $(TZS_NEW) rule.
++# It is separate so that GNU 'make -j' can run instances in parallel.
++$(ZDS): zdump
++		./zdump -i -c $(TZS_YEAR) '$(wd)/'$$(expr $@ : '\(.*\).zd') >$@
++
+ $(TZS_NEW):	tzdata.zi zdump zic
+-		mkdir -p tzs.dir
++		rm -fr tzs.dir
++		mkdir tzs.dir
+ 		$(zic) -d tzs.dir tzdata.zi
+ 		$(AWK) '/^L/{print "Link\t" $$2 "\t" $$3}' \
+ 		   tzdata.zi | LC_ALL=C sort >$@.out
+ 		wd=`pwd` && \
+-		zones=`$(AWK) -v wd="$$wd" \
+-				'/^Z/{print wd "/tzs.dir/" $$2}' tzdata.zi \
+-			 | LC_ALL=C sort` && \
+-		./zdump -i -c $(TZS_YEAR) $$zones >>$@.out
+-		sed 's,^TZ=".*tzs\.dir/,TZ=",' $@.out >$@.sed.out
+-		rm -fr tzs.dir $@.out
+-		mv $@.sed.out $@
++		set x `$(AWK) '/^Z/{print "tzs.dir/" $$2 ".zd"}' tzdata.zi \
++			| LC_ALL=C sort -t . -k 2,2` && \
++		shift && \
++		ZDS=$$* && \
++		$(MAKE) wd="$$wd" TZS_YEAR=$(TZS_YEAR) ZDS="$$ZDS" $$ZDS && \
++		sed 's,^TZ=".*tzs\.dir/,TZ=",' $$ZDS >>$@.out
++		rm -fr tzs.dir
++		mv $@.out $@
+ 
+ # If $(TZS) does not already exist (e.g., old-format tarballs), create it.
+ # If it exists but 'make check_tzs' fails, a maintainer should inspect the
+@@ -669,8 +706,10 @@
+ 		sharp='#' && \
+ 		! grep -Env $(SAFE_LINE) $(MANS) date.1 $(MANTXTS) \
+ 			$(MISC) $(SOURCES) $(WEB_PAGES) \
+-			CONTRIBUTING LICENSE Makefile README \
++			CONTRIBUTING LICENSE README \
+ 			version tzdata.zi && \
++		! grep -Env $(SAFE_LINE)'|^UNUSUAL_OK_CHARSET='$(OK_CHAR)'*$$' \
++			Makefile && \
+ 		! grep -Env $(SAFE_SHARP_LINE) $(TDATA_TO_CHECK) backzone \
+ 			leapseconds yearistype.sh zone.tab && \
+ 		! grep -Env $(OK_LINE) $(ENCHILADA); \
+@@ -702,7 +741,7 @@
+ 		$(AWK) '/^[^#]/ $(CHECK_CC_LIST)' zone1970.tab | \
+ 		  LC_ALL=C sort -cu
+ 
+-check_links:	checklinks.awk $(TDATA_TO_CHECK)
++check_links:	checklinks.awk $(TDATA_TO_CHECK) tzdata.zi
+ 		$(AWK) -f checklinks.awk $(TDATA_TO_CHECK)
+ 		$(AWK) -f checklinks.awk tzdata.zi
+ 
+@@ -720,17 +759,26 @@
+ check_web:	tz-how-to.html
+ 		$(VALIDATE_ENV) $(VALIDATE) $(VALIDATE_FLAGS) tz-how-to.html
+ 
+-# Check that tzdata.zi generates the same binary data that its sources do.
+-check_zishrink: tzdata.zi zic leapseconds $(PACKRATDATA) $(TDATA)
++# Check that zishrink.awk does not alter the data, and that ziguard.awk
++# preserves main-format data.
++check_zishrink: zic leapseconds $(PACKRATDATA) $(TDATA) \
++		  $(DATAFORM).zi tzdata.zi
+ 		for type in posix right; do \
+-		  mkdir -p time_t.dir/$$type time_t.dir/$$type-shrunk && \
++		  mkdir -p time_t.dir/$$type time_t.dir/$$type-t \
++		    time_t.dir/$$type-shrunk && \
+ 		  case $$type in \
+ 		    right) leap='-L leapseconds';; \
+ 	            *) leap=;; \
+ 		  esac && \
+-		  $(ZIC) $$leap -d time_t.dir/$$type $(TDATA) && \
+-		  $(AWK) '/^Rule/' $(TDATA) | \
+-		    $(ZIC) $$leap -d time_t.dir/$$type - $(PACKRATDATA) && \
++		  $(ZIC) $$leap -d time_t.dir/$$type $(DATAFORM).zi && \
++		  case $(DATAFORM) in \
++		    main) \
++		      $(ZIC) $$leap -d time_t.dir/$$type-t $(TDATA) && \
++		      $(AWK) '/^Rule/' $(TDATA) | \
++			$(ZIC) $$leap -d time_t.dir/$$type-t - \
++			  $(PACKRATDATA) && \
++		      diff -r time_t.dir/$$type time_t.dir/$$type-t;; \
++		  esac && \
+ 		  $(ZIC) $$leap -d time_t.dir/$$type-shrunk tzdata.zi && \
+ 		  diff -r time_t.dir/$$type time_t.dir/$$type-shrunk || exit; \
+ 		done
+@@ -740,7 +788,7 @@
+ 		rm -f core *.o *.out \
+ 		  date tzselect version.h zdump zic yearistype libtz.a
+ clean:		clean_misc
+-		rm -fr *.dir tzdata.zi tzdb-*/ $(TZS_NEW)
++		rm -fr *.dir *.zi tzdb-*/ $(TZS_NEW)
+ 
+ maintainer-clean: clean
+ 		@echo 'This command is intended for maintainers to use; it'
+@@ -856,6 +904,9 @@
+ 		VERSION=`cat version` && \
+ 		$(MAKE) VERSION="$$VERSION" $@_version
+ 
++# These *_version rules are intended for use if VERSION is set by some
++# other means.  Ordinarily these rules are used only by the above
++# non-_version rules, which set VERSION on the 'make' command line.
+ tarballs_version: traditional_tarballs_version tzdb-$(VERSION).tar.lz
+ traditional_tarballs_version: \
+   tzcode$(VERSION).tar.gz tzdata$(VERSION).tar.gz
+@@ -917,13 +968,17 @@
+ .KEEP_STATE:
+ 
+ .PHONY: ALL INSTALL all
+-.PHONY: check check_character_set check_links
++.PHONY: check check_character_set check_links check_name_lengths
+ .PHONY: check_public check_sorted check_tables
+ .PHONY: check_time_t_alternatives check_tzs check_web check_white_space
+ .PHONY: check_zishrink
+-.PHONY: clean clean_misc force_tzs
++.PHONY: clean clean_misc dummy.zd force_tzs
+ .PHONY: install install_data maintainer-clean names
+ .PHONY: posix_only posix_packrat posix_right
+ .PHONY: public right_only right_posix signatures signatures_version
+-.PHONY: tarballs tarballs_version typecheck
++.PHONY: tarballs tarballs_version
++.PHONY: traditional_signatures traditional_signatures_version
++.PHONY: traditional_tarballs traditional_tarballs_version
++.PHONY: typecheck
+ .PHONY: zonenames zones
++.PHONY: $(ZDS)
+--- contrib/tzdata/NEWS.orig
++++ contrib/tzdata/NEWS
+@@ -1,9 +1,146 @@
+ News for the tz database
+ 
++Release 2018d - 2018-03-22 07:05:46 -0700
++
++  Briefly:
++
++  Palestine starts DST a week earlier in 2018.
++  Add support for vanguard and rearguard data consumers.
++  Add subsecond precision to source data format, though not to data.
++
++  Changes to future time stamps
++
++    In 2018, Palestine starts DST on March 24, not March 31.
++    Adjust future predictions accordingly.  (Thanks to Sharef Mustafa.)
++
++  Changes to past and future time stamps
++
++    Casey Station in Antarctica changed from +11 to +08 on 2018-03-11
++    at 04:00.  (Thanks to Steffen Thorsen.)
++
++  Changes to past time stamps
++
++    Historical transitions for Uruguay, represented by
++    America/Montevideo, have been updated per official legal documents,
++    replacing previous data mainly originating from the inventions of
++    Shanks & Pottenger.  This has resulted in adjustments ranging from
++    30 to 90 minutes in either direction over at least two dozen
++    distinct periods ranging from one day to several years in length.
++    A mere handful of pre-1991 transitions are unaffected; data since
++    then has come from more reliable contemporaneous reporting.  These
++    changes affect various timestamps in 1920-1923, 1936, 1939,
++    1942-1943, 1959, 1966-1970, 1972, 1974-1980, and 1988-1990.
++    Additionally, Uruguay's pre-standard-time UT offset has been
++    adjusted westward by 7 seconds, from UT-03:44:44 to UT-03:44:51, to
++    match the location of the Observatory of the National Meteorological
++    Institute in Montevideo.
++    (Thanks to Jeremie Bonjour, Tim Parenti, and Michael Deckers.)
++
++    Enderbury and Kiritimati skipped New Year's Eve 1994, not
++    New Year's Day 1995.  (Thanks to Kerry Shetline.)
++
++    Fix the 1912-01-01 transition for Portugual and its colonies.
++    This transition was at 00:00 according to the new UT offset, not
++    according to the old one.  Also assume that Cape Verde switched on
++    the same date as the rest, not in 1907.  This affects
++    Africa/Bissau, Africa/Sao_Tome, Asia/Macau, Atlantic/Azores,
++    Atlantic/Cape_Verde, Atlantic/Madeira, and Europe/Lisbon.
++    (Thanks to Michael Deckers.)
++
++    Fix an off-by-1 error for pre-1913 timestamps in Jamaica and in
++    Turks & Caicos.
++
++  Changes to past time zone abbreviations
++
++    MMT took effect in Uruguay from 1908-06-10, not 1898-06-28.  There
++    is no clock change associated with the transition.
++
++  Changes to build procedure
++
++    The new DATAFORM macro in the Makefile lets the installer choose
++    among three source data formats.  The idea is to lessen downstream
++    disruption when data formats are improved.
++
++    * DATAFORM=vanguard installs from the latest, bleeding-edge
++      format.  DATAFORM=main (the default) installs from the format
++      used in the 'africa' etc. files.  DATAFORM=rearguard installs
++      from a trailing-edge format.  Eventually, elements of today's
++      vanguard format should move to the main format, and similarly
++      the main format's features should eventually move to the
++      rearguard format.
++
++    * In the current version, the main and rearguard formats are
++      identical and match that of 2018c, so this change does not
++      affect default behavior.  The vanguard format currently contains
++      one feature not in the main format: negative SAVE values.  This
++      improves support for Ireland, which uses Irish Standard Time
++      (IST, UTC+01) in summer and GMT (UTC) in winter.  tzcode has
++      supported negative SAVE values for decades, and this feature
++      should move to the main format soon.  However, it will not move
++      to the rearguard format for quite some time because some
++      downstream parsers do not support it.
++
++    * The build procedure constructs three files vanguard.zi, main.zi,
++      and rearguard.zi, one for each format.  The files represent the
++      same data as closely as the formats allow.  These three files
++      are intended for downstream data consumers and are not
++      installed.  Zoneinfo parsers that do not support negative SAVE values
++      should start using rearguard.zi, so that they will be unaffected
++      when the negative-DST feature moves from vanguard to main.
++      Bleeding-edge Zoneinfo parsers that support the new features
++      already can use vanguard.zi; in this respect, current tzcode is
++      bleeding-edge.
++
++    The Makefile should now be safe for parallelized builds, and 'make
++    -j to2050new.tzs' is now much faster on a multiprocessor host
++    with GNU Make.
++
++    When built with -DSUPPRESS_TZDIR, the tzcode library no longer
++    prepends TZDIR/ to file names that do not begin with '/'.  This is
++    not recommended for general use, due to its security implications.
++    (From a suggestion by Manuela Friedrich.)
++
++  Changes to code
++
++    zic now accepts subsecond precision in expressions like
++    00:19:32.13, which is approximately the legal time of the
++    Netherlands from 1835 to 1937.  However, because it is
++    questionable whether the few recorded uses of non-integer offsets
++    had subsecond precision in practice, there are no plans for tzdata
++    to use this feature.  (Thanks to Steve Allen for pointing out
++    the limitations of historical data in this area.)
++
++    The code is a bit more portable to MS-Windows.  Installers can
++    compile with -DRESERVE_STD_EXT_IDS on MS-Windows platforms that
++    reserve identifiers like 'localtime'.  (Thanks to Manuela
++    Friedrich).
++
++  Changes to documentation and commentary
++
++    theory.html now outlines tzdb's extensions to POSIX's model for
++    civil time, and has a section "POSIX features no longer needed"
++    that lists POSIX API components that are now vestigial.
++    (From suggestions by Steve Summit.)  It also better distinguishes
++    time zones from tz regions.  (From a suggestion by Guy Harris.)
++
++    Commentary is now more consistent about using the phrase "daylight
++    saving time", to match the C name tm_isdst.  Daylight saving time
++    need not occur in summer, and need not have a positive offset from
++    standard time.
++
++    Commentary about historical transitions in Uruguay has been expanded
++    with links to many relevant legal documents.
++    (Thanks to Tim Parenti.)
++
++    Commentary now uses some non-ASCII characters with Unicode value
++    less than U+0100, as they can be useful and should work even with
++    older editors such as XEmacs.
++
++
+ Release 2018c - 2018-01-22 23:00:44 -0800
+ 
+   Briefly:
+-  Revert Irish changes that relied on negative DST offsets.
++  Revert Irish changes that relied on negative SAVE values.
+ 
+   Changes to tm_isdst
+ 
+@@ -14,8 +151,8 @@
+     struct tm type.  This reversion is intended to be a temporary
+     workaround for problems discovered with downstream uses of
+     releases 2018a and 2018b, which implemented Irish time by using
+-    negative DST offsets in the Eire rules of the 'europe' file.
+-    Although negative DST offsets have been part of tzcode for many
++    negative SAVE values in the Eire rules of the 'europe' file.
++    Although negative SAVE values have been part of tzcode for many
+     years and are supported by many platforms, they were not
+     documented before 2018a and ICU and OpenJDK do not currently
+     support them.  A mechanism to export data to platforms lacking
+@@ -900,7 +1037,7 @@
+     Comments in zone tables have been improved.  (Thanks to J William Piggott.)
+ 
+     tzselect again limits its menu comments so that menus fit on a
+-    24x80 alphanumeric display.
++    24×80 alphanumeric display.
+ 
+     A new web page tz-how-to.html.  (Thanks to Bill Seymour.)
+ 
+--- contrib/tzdata/africa.orig
++++ contrib/tzdata/africa
+@@ -115,13 +115,13 @@
+ 
+ # Cape Verde / Cabo Verde
+ #
++# From Paul Eggert (2018-02-16):
+ # Shanks gives 1907 for the transition to +02.
+-# Perhaps the 1911-05-26 Portuguese decree
+-# https://dre.pt/pdf1sdip/1911/05/12500/23132313.pdf
+-# merely made it official?
++# For now, ignore that and follow the 1911-05-26 Portuguese decree
++# (see Europe/Lisbon).
+ #
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+-Zone Atlantic/Cape_Verde -1:34:04 -	LMT	1907        # Praia
++Zone Atlantic/Cape_Verde -1:34:04 -	LMT	1912 Jan 01  2:00u # Praia
+ 			-2:00	-	-02	1942 Sep
+ 			-2:00	1:00	-01	1945 Oct 15
+ 			-2:00	-	-02	1975 Nov 25  2:00
+@@ -370,15 +370,34 @@
+ # See Africa/Abidjan.
+ 
+ # Ghana
++
++# From Paul Eggert (2018-01-30):
++# Whitman says DST was observed from 1931 to "the present";
++# Shanks & Pottenger say 1936 to 1942 with 20 minutes of DST,
++# with transitions on 09-01 and 12-31 at 00:00.
++# Page 33 of Parish GCB, Colonial Reports - Annual. No. 1066. Gold
++# Coast. Report for 1919. (March 1921), OCLC 784024077
++# http://libsysdigi.library.illinois.edu/ilharvest/africana/books2011-05/5530214/5530214_1919/5530214_1919_opt.pdf
++# lists the Determination of the Time Ordinance, 1919, No. 18,
++# "to advance the time observed locally by the space of twenty minutes
++# during the last four months of each year; the object in view being
++# to extend during those months the period of daylight-time available
++# for evening recreation after office hours."
++# Vanessa Ogle, The Global Transformation of Time, 1870-1950 (2015), p 33,
++# writes "In 1919, the Gold Coast (Ghana as of 1957) made Greenwich
++# time its legal time and simultaneously legalized a summer time of
++# UTC - 00:20 minutes from March to October."; a footnote lists
++# the ordinance as being dated 1919-11-24.
++# The Crown Colonist, Volume 12 (1942), p 176, says "the Government
++# intend advancing Gold Coast time half an hour ahead of G.M.T.
++# The actual date of the alteration has not yet been announced."
++# These sources are incomplete and contradictory.  Possibly what is
++# now Ghana observed different DST regimes in different years.  For
++# lack of better info, use Shanks except treat the minus sign as a
++# typo, and assume DST started in 1920 not 1936.
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-# Whitman says DST was observed from 1931 to "the present";
+-# Shanks & Pottenger say 1936 to 1942;
+-# and September 1 to January 1 is given by:
+-# Scott Keltie J, Epstein M (eds), The Statesman's Year-Book,
+-# 57th ed. Macmillan, London (1920), OCLC 609408015, pp xxviii.
+-# For lack of better info, assume DST was observed from 1920 to 1942.
+-Rule	Ghana	1920	1942	-	Sep	 1	0:00	0:20	GHST
+-Rule	Ghana	1920	1942	-	Dec	31	0:00	0	GMT
++Rule	Ghana	1920	1942	-	Sep	 1	0:00	0:20	-
++Rule	Ghana	1920	1942	-	Dec	31	0:00	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Africa/Accra	-0:00:52 -	LMT	1918
+ 			 0:00	Ghana	GMT/+0020
+@@ -388,13 +407,13 @@
+ 
+ # Guinea-Bissau
+ #
++# From Paul Eggert (2018-02-16):
+ # Shanks gives 1911-05-26 for the transition to WAT,
+ # evidently confusing the date of the Portuguese decree
+-# https://dre.pt/pdf1sdip/1911/05/12500/23132313.pdf
+-# with the date that it took effect, namely 1912-01-01.
++# (see Europe/Lisbon) with the date that it took effect.
+ #
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+-Zone	Africa/Bissau	-1:02:20 -	LMT	1912 Jan  1
++Zone	Africa/Bissau	-1:02:20 -	LMT	1912 Jan  1  1:00u
+ 			-1:00	-	-01	1975
+ 			 0:00	-	GMT
+ 
+@@ -590,9 +609,9 @@
+ # at 2am (or 02:00) local time..."
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule Mauritius	1982	only	-	Oct	10	0:00	1:00	S
++Rule Mauritius	1982	only	-	Oct	10	0:00	1:00	-
+ Rule Mauritius	1983	only	-	Mar	21	0:00	0	-
+-Rule Mauritius	2008	only	-	Oct	lastSun	2:00	1:00	S
++Rule Mauritius	2008	only	-	Oct	lastSun	2:00	1:00	-
+ Rule Mauritius	2009	only	-	Mar	lastSun	2:00	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone Indian/Mauritius	3:50:00 -	LMT	1907 # Port Louis
+@@ -1037,6 +1056,8 @@
+ 
+ # São Tomé and Príncipe
+ 
++# See Europe/Lisbon for info about the 1912 transition.
++
+ # From Steffen Thorsen (2018-01-08):
+ # Multiple sources tell that São Tomé changed from UTC to UTC+1 as
+ # they entered the year 2018.
+@@ -1045,7 +1066,7 @@
+ # http://www.mnec.gov.st/index.php/publicacoes/documentos/file/90-decreto-lei-n-25-2017
+ 
+ Zone	Africa/Sao_Tome	 0:26:56 -	LMT	1884
+-			-0:36:45 -	LMT	1912 # Lisbon Mean Time
++			-0:36:45 -	LMT	1912 Jan  1 00:00u # Lisbon MT
+ 			 0:00	-	GMT	2018 Jan  1 01:00
+ 			 1:00	-	WAT
+ 
+--- contrib/tzdata/antarctica.orig
++++ contrib/tzdata/antarctica
+@@ -75,7 +75,8 @@
+ 			8:00	-	+08	2011 Oct 28  2:00
+ 			11:00	-	+11	2012 Feb 21 17:00u
+ 			8:00	-	+08	2016 Oct 22
+-			11:00	-	+11
++			11:00	-	+11	2018 Mar 11  4:00
++			8:00	-	+08
+ Zone Antarctica/Davis	0	-	-00	1957 Jan 13
+ 			7:00	-	+07	1964 Nov
+ 			0	-	-00	1969 Feb
+--- contrib/tzdata/asia.orig
++++ contrib/tzdata/asia
+@@ -69,13 +69,13 @@
+ Rule	EUAsia	1981	max	-	Mar	lastSun	 1:00u	1:00	S
+ Rule	EUAsia	1979	1995	-	Sep	lastSun	 1:00u	0	-
+ Rule	EUAsia	1996	max	-	Oct	lastSun	 1:00u	0	-
+-Rule E-EurAsia	1981	max	-	Mar	lastSun	 0:00	1:00	S
++Rule E-EurAsia	1981	max	-	Mar	lastSun	 0:00	1:00	-
+ Rule E-EurAsia	1979	1995	-	Sep	lastSun	 0:00	0	-
+ Rule E-EurAsia	1996	max	-	Oct	lastSun	 0:00	0	-
+-Rule RussiaAsia	1981	1984	-	Apr	1	 0:00	1:00	S
++Rule RussiaAsia	1981	1984	-	Apr	1	 0:00	1:00	-
+ Rule RussiaAsia	1981	1983	-	Oct	1	 0:00	0	-
+ Rule RussiaAsia	1984	1995	-	Sep	lastSun	 2:00s	0	-
+-Rule RussiaAsia	1985	2010	-	Mar	lastSun	 2:00s	1:00	S
++Rule RussiaAsia	1985	2010	-	Mar	lastSun	 2:00s	1:00	-
+ Rule RussiaAsia	1996	2010	-	Oct	lastSun	 2:00s	0	-
+ 
+ # Afghanistan
+@@ -110,7 +110,7 @@
+ # (brief)
+ # http://www.worldtimezone.com/dst_news/dst_news_armenia03.html
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule Armenia	2011	only	-	Mar	lastSun	 2:00s	1:00	S
++Rule Armenia	2011	only	-	Mar	lastSun	 2:00s	1:00	-
+ Rule Armenia	2011	only	-	Oct	lastSun	 2:00s	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Asia/Yerevan	2:58:00 -	LMT	1924 May  2
+@@ -136,7 +136,7 @@
+ # http://en.apa.az/xeber_azerbaijan_abolishes_daylight_savings_ti_240862.html
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Azer	1997	2015	-	Mar	lastSun	 4:00	1:00	S
++Rule	Azer	1997	2015	-	Mar	lastSun	 4:00	1:00	-
+ Rule	Azer	1997	2015	-	Oct	lastSun	 5:00	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Asia/Baku	3:19:24 -	LMT	1924 May  2
+@@ -223,7 +223,7 @@
+ # http://www.worldtimezone.com/dst_news/dst_news_bangladesh06.html
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Dhaka	2009	only	-	Jun	19	23:00	1:00	S
++Rule	Dhaka	2009	only	-	Jun	19	23:00	1:00	-
+ Rule	Dhaka	2009	only	-	Dec	31	24:00	0	-
+ 
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+@@ -764,8 +764,9 @@
+ Rule	Macau	1975	1977	-	Apr	Sun>=15	3:30	1:00	D
+ Rule	Macau	1978	1980	-	Apr	Sun>=15	0:00	1:00	D
+ Rule	Macau	1978	1980	-	Oct	Sun>=15	0:00	0	S
++# See Europe/Lisbon for info about the 1912 transition.
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+-Zone	Asia/Macau	7:34:20 -	LMT	1912 Jan  1
++Zone	Asia/Macau	7:34:20 -	LMT	1911 Dec 31 16:00u
+ 			8:00	Macau	C%sT
+ 
+ 
+@@ -1106,53 +1107,53 @@
+ # thirtieth day of Shahrivar.
+ #
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Iran	1978	1980	-	Mar	21	0:00	1:00	D
+-Rule	Iran	1978	only	-	Oct	21	0:00	0	S
+-Rule	Iran	1979	only	-	Sep	19	0:00	0	S
+-Rule	Iran	1980	only	-	Sep	23	0:00	0	S
+-Rule	Iran	1991	only	-	May	 3	0:00	1:00	D
+-Rule	Iran	1992	1995	-	Mar	22	0:00	1:00	D
+-Rule	Iran	1991	1995	-	Sep	22	0:00	0	S
+-Rule	Iran	1996	only	-	Mar	21	0:00	1:00	D
+-Rule	Iran	1996	only	-	Sep	21	0:00	0	S
+-Rule	Iran	1997	1999	-	Mar	22	0:00	1:00	D
+-Rule	Iran	1997	1999	-	Sep	22	0:00	0	S
+-Rule	Iran	2000	only	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2000	only	-	Sep	21	0:00	0	S
+-Rule	Iran	2001	2003	-	Mar	22	0:00	1:00	D
+-Rule	Iran	2001	2003	-	Sep	22	0:00	0	S
+-Rule	Iran	2004	only	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2004	only	-	Sep	21	0:00	0	S
+-Rule	Iran	2005	only	-	Mar	22	0:00	1:00	D
+-Rule	Iran	2005	only	-	Sep	22	0:00	0	S
+-Rule	Iran	2008	only	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2008	only	-	Sep	21	0:00	0	S
+-Rule	Iran	2009	2011	-	Mar	22	0:00	1:00	D
+-Rule	Iran	2009	2011	-	Sep	22	0:00	0	S
+-Rule	Iran	2012	only	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2012	only	-	Sep	21	0:00	0	S
+-Rule	Iran	2013	2015	-	Mar	22	0:00	1:00	D
+-Rule	Iran	2013	2015	-	Sep	22	0:00	0	S
+-Rule	Iran	2016	only	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2016	only	-	Sep	21	0:00	0	S
+-Rule	Iran	2017	2019	-	Mar	22	0:00	1:00	D
+-Rule	Iran	2017	2019	-	Sep	22	0:00	0	S
+-Rule	Iran	2020	only	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2020	only	-	Sep	21	0:00	0	S
+-Rule	Iran	2021	2023	-	Mar	22	0:00	1:00	D
+-Rule	Iran	2021	2023	-	Sep	22	0:00	0	S
+-Rule	Iran	2024	only	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2024	only	-	Sep	21	0:00	0	S
+-Rule	Iran	2025	2027	-	Mar	22	0:00	1:00	D
+-Rule	Iran	2025	2027	-	Sep	22	0:00	0	S
+-Rule	Iran	2028	2029	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2028	2029	-	Sep	21	0:00	0	S
+-Rule	Iran	2030	2031	-	Mar	22	0:00	1:00	D
+-Rule	Iran	2030	2031	-	Sep	22	0:00	0	S
+-Rule	Iran	2032	2033	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2032	2033	-	Sep	21	0:00	0	S
+-Rule	Iran	2034	2035	-	Mar	22	0:00	1:00	D
+-Rule	Iran	2034	2035	-	Sep	22	0:00	0	S
++Rule	Iran	1978	1980	-	Mar	21	0:00	1:00	-
++Rule	Iran	1978	only	-	Oct	21	0:00	0	-
++Rule	Iran	1979	only	-	Sep	19	0:00	0	-
++Rule	Iran	1980	only	-	Sep	23	0:00	0	-
++Rule	Iran	1991	only	-	May	 3	0:00	1:00	-
++Rule	Iran	1992	1995	-	Mar	22	0:00	1:00	-
++Rule	Iran	1991	1995	-	Sep	22	0:00	0	-
++Rule	Iran	1996	only	-	Mar	21	0:00	1:00	-
++Rule	Iran	1996	only	-	Sep	21	0:00	0	-
++Rule	Iran	1997	1999	-	Mar	22	0:00	1:00	-
++Rule	Iran	1997	1999	-	Sep	22	0:00	0	-
++Rule	Iran	2000	only	-	Mar	21	0:00	1:00	-
++Rule	Iran	2000	only	-	Sep	21	0:00	0	-
++Rule	Iran	2001	2003	-	Mar	22	0:00	1:00	-
++Rule	Iran	2001	2003	-	Sep	22	0:00	0	-
++Rule	Iran	2004	only	-	Mar	21	0:00	1:00	-
++Rule	Iran	2004	only	-	Sep	21	0:00	0	-
++Rule	Iran	2005	only	-	Mar	22	0:00	1:00	-
++Rule	Iran	2005	only	-	Sep	22	0:00	0	-
++Rule	Iran	2008	only	-	Mar	21	0:00	1:00	-
++Rule	Iran	2008	only	-	Sep	21	0:00	0	-
++Rule	Iran	2009	2011	-	Mar	22	0:00	1:00	-
++Rule	Iran	2009	2011	-	Sep	22	0:00	0	-
++Rule	Iran	2012	only	-	Mar	21	0:00	1:00	-
++Rule	Iran	2012	only	-	Sep	21	0:00	0	-
++Rule	Iran	2013	2015	-	Mar	22	0:00	1:00	-
++Rule	Iran	2013	2015	-	Sep	22	0:00	0	-
++Rule	Iran	2016	only	-	Mar	21	0:00	1:00	-
++Rule	Iran	2016	only	-	Sep	21	0:00	0	-
++Rule	Iran	2017	2019	-	Mar	22	0:00	1:00	-
++Rule	Iran	2017	2019	-	Sep	22	0:00	0	-
++Rule	Iran	2020	only	-	Mar	21	0:00	1:00	-
++Rule	Iran	2020	only	-	Sep	21	0:00	0	-
++Rule	Iran	2021	2023	-	Mar	22	0:00	1:00	-
++Rule	Iran	2021	2023	-	Sep	22	0:00	0	-
++Rule	Iran	2024	only	-	Mar	21	0:00	1:00	-
++Rule	Iran	2024	only	-	Sep	21	0:00	0	-
++Rule	Iran	2025	2027	-	Mar	22	0:00	1:00	-
++Rule	Iran	2025	2027	-	Sep	22	0:00	0	-
++Rule	Iran	2028	2029	-	Mar	21	0:00	1:00	-
++Rule	Iran	2028	2029	-	Sep	21	0:00	0	-
++Rule	Iran	2030	2031	-	Mar	22	0:00	1:00	-
++Rule	Iran	2030	2031	-	Sep	22	0:00	0	-
++Rule	Iran	2032	2033	-	Mar	21	0:00	1:00	-
++Rule	Iran	2032	2033	-	Sep	21	0:00	0	-
++Rule	Iran	2034	2035	-	Mar	22	0:00	1:00	-
++Rule	Iran	2034	2035	-	Sep	22	0:00	0	-
+ #
+ # The following rules are approximations starting in the year 2038.
+ # These are the best post-2037 approximations available, given the
+@@ -1159,8 +1160,8 @@
+ # restrictions of a single rule using a Gregorian-based data format.
+ # At some point this table will need to be extended, though quite
+ # possibly Iran will change the rules first.
+-Rule	Iran	2036	max	-	Mar	21	0:00	1:00	D
+-Rule	Iran	2036	max	-	Sep	21	0:00	0	S
++Rule	Iran	2036	max	-	Mar	21	0:00	1:00	-
++Rule	Iran	2036	max	-	Sep	21	0:00	0	-
+ 
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Asia/Tehran	3:25:44	-	LMT	1916
+@@ -1196,17 +1197,17 @@
+ # https://www.timeanddate.com/news/time/iraq-dumps-daylight-saving.html
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Iraq	1982	only	-	May	1	0:00	1:00	D
+-Rule	Iraq	1982	1984	-	Oct	1	0:00	0	S
+-Rule	Iraq	1983	only	-	Mar	31	0:00	1:00	D
+-Rule	Iraq	1984	1985	-	Apr	1	0:00	1:00	D
+-Rule	Iraq	1985	1990	-	Sep	lastSun	1:00s	0	S
+-Rule	Iraq	1986	1990	-	Mar	lastSun	1:00s	1:00	D
++Rule	Iraq	1982	only	-	May	1	0:00	1:00	-
++Rule	Iraq	1982	1984	-	Oct	1	0:00	0	-
++Rule	Iraq	1983	only	-	Mar	31	0:00	1:00	-
++Rule	Iraq	1984	1985	-	Apr	1	0:00	1:00	-
++Rule	Iraq	1985	1990	-	Sep	lastSun	1:00s	0	-
++Rule	Iraq	1986	1990	-	Mar	lastSun	1:00s	1:00	-
+ # IATA SSIM (1991/1996) says Apr 1 12:01am UTC; guess the ':01' is a typo.
+ # Shanks & Pottenger say Iraq did not observe DST 1992/1997; ignore this.
+ #
+-Rule	Iraq	1991	2007	-	Apr	 1	3:00s	1:00	D
+-Rule	Iraq	1991	2007	-	Oct	 1	3:00s	0	S
++Rule	Iraq	1991	2007	-	Apr	 1	3:00s	1:00	-
++Rule	Iraq	1991	2007	-	Oct	 1	3:00s	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Asia/Baghdad	2:57:40	-	LMT	1890
+ 			2:57:36	-	BMT	1918     # Baghdad Mean Time?
+@@ -1478,8 +1479,7 @@
+ 
+ # From Hideyuki Suzuki (1998-11-09):
+ # 'Tokyo' usually stands for the former location of Tokyo Astronomical
+-# Observatory: 139 degrees 44' 40.90" E (9h 18m 58.727s),
+-# 35 degrees 39' 16.0" N.
++# Observatory: 139° 44' 40.90" E (9h 18m 58.727s), 35° 39' 16.0" N.
+ # This data is from 'Rika Nenpyou (Chronological Scientific Tables) 1996'
+ # edited by National Astronomical Observatory of Japan....
+ # JST (Japan Standard Time) has been used since 1888-01-01 00:00 (JST).
+@@ -1487,10 +1487,10 @@
+ 
+ # From Hideyuki Suzuki (1998-11-16):
+ # The ordinance No. 51 (1886) established "standard time" in Japan,
+-# which stands for the time on 135 degrees E.
++# which stands for the time on 135° E.
+ # In the ordinance No. 167 (1895), "standard time" was renamed to "central
+ # standard time".  And the same ordinance also established "western standard
+-# time", which stands for the time on 120 degrees E....  But "western standard
++# time", which stands for the time on 120° E....  But "western standard
+ # time" was abolished in the ordinance No. 529 (1937).  In the ordinance No.
+ # 167, there is no mention regarding for what place western standard time is
+ # standard....
+@@ -1903,9 +1903,9 @@
+ # From 2005-08-12 our GMT-offset is +6, w/o any daylight saving.
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Kyrgyz	1992	1996	-	Apr	Sun>=7	0:00s	1:00	S
++Rule	Kyrgyz	1992	1996	-	Apr	Sun>=7	0:00s	1:00	-
+ Rule	Kyrgyz	1992	1996	-	Sep	lastSun	0:00	0	-
+-Rule	Kyrgyz	1997	2005	-	Mar	lastSun	2:30	1:00	S
++Rule	Kyrgyz	1997	2005	-	Mar	lastSun	2:30	1:00	-
+ Rule	Kyrgyz	1997	2004	-	Oct	lastSun	2:30	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Asia/Bishkek	4:58:24 -	LMT	1924 May  2
+@@ -2037,7 +2037,7 @@
+ 
+ # Malaysia
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	NBorneo	1935	1941	-	Sep	14	0:00	0:20	TS # one-Third Summer
++Rule	NBorneo	1935	1941	-	Sep	14	0:00	0:20	-
+ Rule	NBorneo	1935	1941	-	Dec	14	0:00	0	-
+ #
+ # peninsular Malaysia
+@@ -2182,7 +2182,7 @@
+ # http://zasag.mn/news/view/8969
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Mongol	1983	1984	-	Apr	1	0:00	1:00	S
++Rule	Mongol	1983	1984	-	Apr	1	0:00	1:00	-
+ Rule	Mongol	1983	only	-	Oct	1	0:00	0	-
+ # Shanks & Pottenger and IATA SSIM say 1990s switches occurred at 00:00,
+ # but McDow says the 2001 switches occurred at 02:00.  Also, IATA SSIM
+@@ -2199,13 +2199,13 @@
+ # Mongolian Government meeting has concluded today to cancel daylight
+ # saving time adoption in Mongolia.  Source: http://zasag.mn/news/view/16192
+ 
+-Rule	Mongol	1985	1998	-	Mar	lastSun	0:00	1:00	S
++Rule	Mongol	1985	1998	-	Mar	lastSun	0:00	1:00	-
+ Rule	Mongol	1984	1998	-	Sep	lastSun	0:00	0	-
+ # IATA SSIM (1999-09) says Mongolia no longer observes DST.
+-Rule	Mongol	2001	only	-	Apr	lastSat	2:00	1:00	S
++Rule	Mongol	2001	only	-	Apr	lastSat	2:00	1:00	-
+ Rule	Mongol	2001	2006	-	Sep	lastSat	2:00	0	-
+-Rule	Mongol	2002	2006	-	Mar	lastSat	2:00	1:00	S
+-Rule	Mongol	2015	2016	-	Mar	lastSat	2:00	1:00	S
++Rule	Mongol	2002	2006	-	Mar	lastSat	2:00	1:00	-
++Rule	Mongol	2015	2016	-	Mar	lastSat	2:00	1:00	-
+ Rule	Mongol	2015	2016	-	Sep	lastSat	0:00	0	-
+ 
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+@@ -2639,9 +2639,6 @@
+ # [Google translation]: "The Council also decided to start daylight
+ # saving in Palestine as of one o'clock on Saturday morning,
+ # 2016-03-26, to provide the clock 60 minutes ahead."
+-#
+-# From Paul Eggert (2016-03-12):
+-# Predict spring transitions on March's last Saturday at 01:00 from now on.
+ 
+ # From Sharef Mustafa (2016-10-19):
+ # [T]he Palestinian cabinet decision (Mar 8th 2016) published on
+@@ -2658,6 +2655,16 @@
+ # https://www.timeanddate.com/time/change/gaza-strip/gaza
+ # https://www.timeanddate.com/time/change/west-bank/hebron
+ 
++# From Sharef Mustafa (2018-03-16):
++# Palestine summer time will start on Mar 24th 2018 by advancing the
++# clock by 60 minutes as per Palestinian cabinet decision published on
++# the offical website, though the decree did not specify the exact
++# time of the time shift.
++# http://www.palestinecabinet.gov.ps/Website/AR/NDecrees/ViewFile.ashx?ID=e7a42ab7-ee23-435a-b9c8-a4f7e81f3817
++#
++# From Paul Eggert (2018-03-16):
++# For 2016 on, predict spring transitions on March's fourth Saturday at 01:00.
++
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+ Rule EgyptAsia	1957	only	-	May	10	0:00	1:00	S
+ Rule EgyptAsia	1957	1958	-	Oct	 1	0:00	0	-
+@@ -2687,7 +2694,7 @@
+ Rule Palestine	2013	only	-	Sep	Fri>=21	0:00	0	-
+ Rule Palestine	2014	2015	-	Oct	Fri>=21	0:00	0	-
+ Rule Palestine	2015	only	-	Mar	lastFri	24:00	1:00	S
+-Rule Palestine	2016	max	-	Mar	lastSat	1:00	1:00	S
++Rule Palestine	2016	max	-	Mar	Sat>=22	1:00	1:00	S
+ Rule Palestine	2016	max	-	Oct	lastSat	1:00	0	-
+ 
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+@@ -2737,11 +2744,11 @@
+ # http://www.philstar.com/headlines/2014/08/05/1354152/pnoy-urged-declare-use-daylight-saving-time
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Phil	1936	only	-	Nov	1	0:00	1:00	S
++Rule	Phil	1936	only	-	Nov	1	0:00	1:00	-
+ Rule	Phil	1937	only	-	Feb	1	0:00	0	-
+-Rule	Phil	1954	only	-	Apr	12	0:00	1:00	S
++Rule	Phil	1954	only	-	Apr	12	0:00	1:00	-
+ Rule	Phil	1954	only	-	Jul	1	0:00	0	-
+-Rule	Phil	1978	only	-	Mar	22	0:00	1:00	S
++Rule	Phil	1978	only	-	Mar	22	0:00	1:00	-
+ Rule	Phil	1978	only	-	Sep	21	0:00	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Asia/Manila	-15:56:00 -	LMT	1844 Dec 31
+@@ -3097,9 +3104,9 @@
+ # and is the basis for the information below.
+ #
+ # The 1906 transition was effective July 1 and standardized Indochina to
+-# Phù Liễn Observatory, legally 104 deg. 17'17" east of Paris.
++# Phù Liễn Observatory, legally 104° 17' 17" east of Paris.
+ # It's unclear whether this meant legal Paris Mean Time (00:09:21) or
+-# the Paris Meridian (2 deg. 20'14.03" E); the former yields 07:06:30.1333...
++# the Paris Meridian (2° 20' 14.03" E); the former yields 07:06:30.1333...
+ # and the latter 07:06:29.333... so either way it rounds to 07:06:30,
+ # which is used below even though the modern-day Phù Liễn Observatory
+ # is closer to 07:06:31.  Abbreviate Phù Liễn Mean Time as PLMT.
+--- contrib/tzdata/australasia.orig
++++ contrib/tzdata/australasia
+@@ -196,20 +196,20 @@
+ 
+ # Lord Howe Island
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	LH	1981	1984	-	Oct	lastSun	2:00	1:00	D
+-Rule	LH	1982	1985	-	Mar	Sun>=1	2:00	0	S
+-Rule	LH	1985	only	-	Oct	lastSun	2:00	0:30	D
+-Rule	LH	1986	1989	-	Mar	Sun>=15	2:00	0	S
+-Rule	LH	1986	only	-	Oct	19	2:00	0:30	D
+-Rule	LH	1987	1999	-	Oct	lastSun	2:00	0:30	D
+-Rule	LH	1990	1995	-	Mar	Sun>=1	2:00	0	S
+-Rule	LH	1996	2005	-	Mar	lastSun	2:00	0	S
+-Rule	LH	2000	only	-	Aug	lastSun	2:00	0:30	D
+-Rule	LH	2001	2007	-	Oct	lastSun	2:00	0:30	D
+-Rule	LH	2006	only	-	Apr	Sun>=1	2:00	0	S
+-Rule	LH	2007	only	-	Mar	lastSun	2:00	0	S
+-Rule	LH	2008	max	-	Apr	Sun>=1	2:00	0	S
+-Rule	LH	2008	max	-	Oct	Sun>=1	2:00	0:30	D
++Rule	LH	1981	1984	-	Oct	lastSun	2:00	1:00	-
++Rule	LH	1982	1985	-	Mar	Sun>=1	2:00	0	-
++Rule	LH	1985	only	-	Oct	lastSun	2:00	0:30	-
++Rule	LH	1986	1989	-	Mar	Sun>=15	2:00	0	-
++Rule	LH	1986	only	-	Oct	19	2:00	0:30	-
++Rule	LH	1987	1999	-	Oct	lastSun	2:00	0:30	-
++Rule	LH	1990	1995	-	Mar	Sun>=1	2:00	0	-
++Rule	LH	1996	2005	-	Mar	lastSun	2:00	0	-
++Rule	LH	2000	only	-	Aug	lastSun	2:00	0:30	-
++Rule	LH	2001	2007	-	Oct	lastSun	2:00	0:30	-
++Rule	LH	2006	only	-	Apr	Sun>=1	2:00	0	-
++Rule	LH	2007	only	-	Mar	lastSun	2:00	0	-
++Rule	LH	2008	max	-	Apr	Sun>=1	2:00	0	-
++Rule	LH	2008	max	-	Oct	Sun>=1	2:00	0:30	-
+ Zone Australia/Lord_Howe 10:36:20 -	LMT	1895 Feb
+ 			10:00	-	AEST	1981 Mar
+ 			10:30	LH	+1030/+1130 1985 Jul
+@@ -367,15 +367,15 @@
+ # practice than guessing no DST.
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Fiji	1998	1999	-	Nov	Sun>=1	2:00	1:00	S
++Rule	Fiji	1998	1999	-	Nov	Sun>=1	2:00	1:00	-
+ Rule	Fiji	1999	2000	-	Feb	lastSun	3:00	0	-
+-Rule	Fiji	2009	only	-	Nov	29	2:00	1:00	S
++Rule	Fiji	2009	only	-	Nov	29	2:00	1:00	-
+ Rule	Fiji	2010	only	-	Mar	lastSun	3:00	0	-
+-Rule	Fiji	2010	2013	-	Oct	Sun>=21	2:00	1:00	S
++Rule	Fiji	2010	2013	-	Oct	Sun>=21	2:00	1:00	-
+ Rule	Fiji	2011	only	-	Mar	Sun>=1	3:00	0	-
+ Rule	Fiji	2012	2013	-	Jan	Sun>=18	3:00	0	-
+ Rule	Fiji	2014	only	-	Jan	Sun>=18	2:00	0	-
+-Rule	Fiji	2014	max	-	Nov	Sun>=1	2:00	1:00	S
++Rule	Fiji	2014	max	-	Nov	Sun>=1	2:00	1:00	-
+ Rule	Fiji	2015	max	-	Jan	Sun>=14	3:00	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Pacific/Fiji	11:55:44 -	LMT	1915 Oct 26 # Suva
+@@ -406,11 +406,11 @@
+ 			 12:00	-	+12
+ Zone Pacific/Enderbury	-11:24:20 -	LMT	1901
+ 			-12:00	-	-12	1979 Oct
+-			-11:00	-	-11	1995
++			-11:00	-	-11	1994 Dec 31
+ 			 13:00	-	+13
+ Zone Pacific/Kiritimati	-10:29:20 -	LMT	1901
+ 			-10:40	-	-1040	1979 Oct
+-			-10:00	-	-10	1995
++			-10:00	-	-10	1994 Dec 31
+ 			 14:00	-	+14
+ 
+ # N Mariana Is
+@@ -447,9 +447,9 @@
+ 
+ # New Caledonia
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	NC	1977	1978	-	Dec	Sun>=1	0:00	1:00	S
++Rule	NC	1977	1978	-	Dec	Sun>=1	0:00	1:00	-
+ Rule	NC	1978	1979	-	Feb	27	0:00	0	-
+-Rule	NC	1996	only	-	Dec	 1	2:00s	1:00	S
++Rule	NC	1996	only	-	Dec	 1	2:00s	1:00	-
+ # Shanks & Pottenger say the following was at 2:00; go with IATA.
+ Rule	NC	1997	only	-	Mar	 2	2:00s	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+@@ -469,27 +469,28 @@
+ Rule	NZ	1934	1940	-	Apr	lastSun	2:00	0	M
+ Rule	NZ	1934	1940	-	Sep	lastSun	2:00	0:30	S
+ Rule	NZ	1946	only	-	Jan	 1	0:00	0	S
+-# Since 1957 Chatham has been 45 minutes ahead of NZ, but there's no
+-# convenient single notation for the date and time of this transition
+-# so we must duplicate the Rule lines.
++# Since 1957 Chatham has been 45 minutes ahead of NZ, but until 2018a
++# there was no documented single notation for the date and time of this
++# transition.  Duplicate the Rule lines for now, to give the 2018a change
++# time to percolate out.
+ Rule	NZ	1974	only	-	Nov	Sun>=1	2:00s	1:00	D
+-Rule	Chatham	1974	only	-	Nov	Sun>=1	2:45s	1:00	D
++Rule	Chatham	1974	only	-	Nov	Sun>=1	2:45s	1:00	-
+ Rule	NZ	1975	only	-	Feb	lastSun	2:00s	0	S
+-Rule	Chatham	1975	only	-	Feb	lastSun	2:45s	0	S
++Rule	Chatham	1975	only	-	Feb	lastSun	2:45s	0	-
+ Rule	NZ	1975	1988	-	Oct	lastSun	2:00s	1:00	D
+-Rule	Chatham	1975	1988	-	Oct	lastSun	2:45s	1:00	D
++Rule	Chatham	1975	1988	-	Oct	lastSun	2:45s	1:00	-
+ Rule	NZ	1976	1989	-	Mar	Sun>=1	2:00s	0	S
+-Rule	Chatham	1976	1989	-	Mar	Sun>=1	2:45s	0	S
++Rule	Chatham	1976	1989	-	Mar	Sun>=1	2:45s	0	-
+ Rule	NZ	1989	only	-	Oct	Sun>=8	2:00s	1:00	D
+-Rule	Chatham	1989	only	-	Oct	Sun>=8	2:45s	1:00	D
++Rule	Chatham	1989	only	-	Oct	Sun>=8	2:45s	1:00	-
+ Rule	NZ	1990	2006	-	Oct	Sun>=1	2:00s	1:00	D
+-Rule	Chatham	1990	2006	-	Oct	Sun>=1	2:45s	1:00	D
++Rule	Chatham	1990	2006	-	Oct	Sun>=1	2:45s	1:00	-
+ Rule	NZ	1990	2007	-	Mar	Sun>=15	2:00s	0	S
+-Rule	Chatham	1990	2007	-	Mar	Sun>=15	2:45s	0	S
++Rule	Chatham	1990	2007	-	Mar	Sun>=15	2:45s	0	-
+ Rule	NZ	2007	max	-	Sep	lastSun	2:00s	1:00	D
+-Rule	Chatham	2007	max	-	Sep	lastSun	2:45s	1:00	D
++Rule	Chatham	2007	max	-	Sep	lastSun	2:45s	1:00	-
+ Rule	NZ	2008	max	-	Apr	Sun>=1	2:00s	0	S
+-Rule	Chatham	2008	max	-	Apr	Sun>=1	2:45s	0	S
++Rule	Chatham	2008	max	-	Apr	Sun>=1	2:45s	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone Pacific/Auckland	11:39:04 -	LMT	1868 Nov  2
+ 			11:30	NZ	NZ%sT	1946 Jan  1
+@@ -513,9 +514,9 @@
+ # Cook Is
+ # From Shanks & Pottenger:
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Cook	1978	only	-	Nov	12	0:00	0:30	HS
++Rule	Cook	1978	only	-	Nov	12	0:00	0:30	-
+ Rule	Cook	1979	1991	-	Mar	Sun>=1	0:00	0	-
+-Rule	Cook	1979	1990	-	Oct	lastSun	0:00	0:30	HS
++Rule	Cook	1979	1990	-	Oct	lastSun	0:00	0:30	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone Pacific/Rarotonga	-10:39:04 -	LMT	1901        # Avarua
+ 			-10:30	-	-1030	1978 Nov 12
+@@ -656,11 +657,11 @@
+ # Assume the pattern instituted in 2012 will continue indefinitely.
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	WS	2010	only	-	Sep	lastSun	0:00	1	D
+-Rule	WS	2011	only	-	Apr	Sat>=1	4:00	0	S
+-Rule	WS	2011	only	-	Sep	lastSat	3:00	1	D
+-Rule	WS	2012	max	-	Apr	Sun>=1	4:00	0	S
+-Rule	WS	2012	max	-	Sep	lastSun	3:00	1	D
++Rule	WS	2010	only	-	Sep	lastSun	0:00	1	-
++Rule	WS	2011	only	-	Apr	Sat>=1	4:00	0	-
++Rule	WS	2011	only	-	Sep	lastSat	3:00	1	-
++Rule	WS	2012	max	-	Apr	Sun>=1	4:00	0	-
++Rule	WS	2012	max	-	Sep	lastSun	3:00	1	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone Pacific/Apia	 12:33:04 -	LMT	1892 Jul  5
+ 			-11:26:56 -	LMT	1911
+@@ -700,11 +701,11 @@
+ 
+ # Tonga
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Tonga	1999	only	-	Oct	 7	2:00s	1:00	S
++Rule	Tonga	1999	only	-	Oct	 7	2:00s	1:00	-
+ Rule	Tonga	2000	only	-	Mar	19	2:00s	0	-
+-Rule	Tonga	2000	2001	-	Nov	Sun>=1	2:00	1:00	S
++Rule	Tonga	2000	2001	-	Nov	Sun>=1	2:00	1:00	-
+ Rule	Tonga	2001	2002	-	Jan	lastSun	2:00	0	-
+-Rule	Tonga	2016	only	-	Nov	Sun>=1	2:00	1:00	S
++Rule	Tonga	2016	only	-	Nov	Sun>=1	2:00	1:00	-
+ Rule	Tonga	2017	only	-	Jan	Sun>=15	3:00	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone Pacific/Tongatapu	12:19:20 -	LMT	1901
+@@ -781,12 +782,12 @@
+ 
+ # Vanuatu
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Vanuatu	1983	only	-	Sep	25	0:00	1:00	S
++Rule	Vanuatu	1983	only	-	Sep	25	0:00	1:00	-
+ Rule	Vanuatu	1984	1991	-	Mar	Sun>=23	0:00	0	-
+-Rule	Vanuatu	1984	only	-	Oct	23	0:00	1:00	S
+-Rule	Vanuatu	1985	1991	-	Sep	Sun>=23	0:00	1:00	S
++Rule	Vanuatu	1984	only	-	Oct	23	0:00	1:00	-
++Rule	Vanuatu	1985	1991	-	Sep	Sun>=23	0:00	1:00	-
+ Rule	Vanuatu	1992	1993	-	Jan	Sun>=23	0:00	0	-
+-Rule	Vanuatu	1992	only	-	Oct	Sun>=23	0:00	1:00	S
++Rule	Vanuatu	1992	only	-	Oct	Sun>=23	0:00	1:00	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Pacific/Efate	11:13:16 -	LMT	1912 Jan 13 # Vila
+ 			11:00	Vanuatu	+11/+12
+@@ -1085,6 +1086,13 @@
+ # South Australian time even though it's located in Western Australia.
+ 
+ # Queensland
++
++# From Paul Eggert (2018-02-26):
++# I lack access to the following source for Queensland DST:
++# Pearce C. History of daylight saving time in Queensland.
++# Queensland Hist J. 2017 Aug;23(6):389-403
++# https://search.informit.com.au/documentSummary;dn=994682348436426;res=IELHSS
++
+ # From George Shepherd via Simon Woodhead via Robert Elz (1991-03-06):
+ # #   The state of QUEENSLAND.. [ Courtesy Qld. Dept Premier Econ&Trade Devel ]
+ # #						[ Dec 1990 ]
+@@ -1511,6 +1519,12 @@
+ # "declared it the same day [throughout] the country as of Jan. 1, 1995"
+ # as part of the competition to be first into the 21st century.
+ 
++# From Kerry Shetline (2018-02-03):
++# December 31 was the day that was skipped, so that the transition
++# would be from Friday December 30, 1994 to Sunday January 1, 1995.
++# From Paul Eggert (2018-02-04):
++# One source for this is page 202 of: Bartky IR. One Time Fits All:
++# The Campaigns for Global Uniformity (2007).
+ 
+ # Kwajalein
+ 
+@@ -1603,7 +1617,7 @@
+ 
+ # From Howie Phelps (1999-11-10), who talked to a Pitcairner via shortwave:
+ # Betty Christian told me yesterday that their local time is the same as
+-# Pacific Standard Time. They used to be 1/2 hour different from us here in
++# Pacific Standard Time. They used to be ½ hour different from us here in
+ # Sacramento but it was changed a couple of years ago.
+ 
+ 
+@@ -1642,7 +1656,7 @@
+ # 12 hours and 20 minutes ahead of GMT.  When New Zealand adjusted its
+ # standard time in 1940s, Tonga had the choice of subtracting from its
+ # local time to come on the same standard time as New Zealand or of
+-# advancing its time to maintain the differential of 13 degrees
++# advancing its time to maintain the differential of 13°
+ # (approximately 50 minutes ahead of New Zealand time).
+ #
+ # Because His Majesty King Tāufaʻāhau Tupou IV, then Crown Prince
+--- contrib/tzdata/backzone.orig
++++ contrib/tzdata/backzone
+@@ -170,13 +170,13 @@
+ 
+ # Angola
+ #
++# From Paul Eggert (2018-02-16):
+ # Shanks gives 1911-05-26 for the transition to WAT,
+ # evidently confusing the date of the Portuguese decree
+-# https://dre.pt/pdf1sdip/1911/05/12500/23132313.pdf
+-# with the date that it took effect, namely 1912-01-01.
++# (see Europe/Lisbon) with the date that it took effect.
+ #
+ Zone	Africa/Luanda	0:52:56	-	LMT	1892
+-			0:52:04	-	LMT	1912 Jan  1 # Luanda Mean Time?
++			0:52:04	-	LMT	1911 Dec 31 23:00u # Luanda MT?
+ 			1:00	-	WAT
+ 
+ # Democratic Republic of the Congo (east)
+@@ -271,9 +271,19 @@
+ 
+ # Cayman Is
+ Zone	America/Cayman	-5:25:32 -	LMT	1890     # Georgetown
+-			-5:07:11 -	KMT	1912 Feb # Kingston Mean Time
++			-5:07:10 -	KMT	1912 Feb # Kingston Mean Time
+ 			-5:00	-	EST
+ 
++# United States
++#
++# From Paul Eggert (2018-03-18):
++# America/Chillicothe would be tricky, as it was a city of two-timers:
++# "To prevent a constant mixup at Chillicothe, caused by the courthouse
++#  clock running on central time and the city running on 'daylight saving'
++#  time, a third hand was added to the dial of the courthouse clock."
++# -- Ohio news in brief. The Cedarville Herald. 1920-05-21;43(21):1 (col. 5)
++# https://digitalcommons.cedarville.edu/cedarville_herald/794
++
+ # Canada
+ Zone America/Coral_Harbour -5:32:40 -	LMT	1884
+ 			-5:00	NT_YK	E%sT	1946
+@@ -348,6 +358,30 @@
+ Zone America/Montserrat	-4:08:52 -	LMT	1911 Jul  1  0:01 # Cork Hill
+ 			-4:00	-	AST
+ 
++# United States
++#
++# From Paul Eggert (2018-03-18):
++# America/Palm_Springs would be tricky, as it kept two sets of clocks
++# in 1946/7.  See the following notes.
++#
++# From Steve Allen (2018-01-19):
++# The shadow of Mt. San Jacinto brings darkness very early in the winter
++# months.  In 1946 the chamber of commerce decided to put the clocks of Palm
++# Springs forward by an hour in the winter.
++# https://www.desertsun.com/story/life/2017/12/27/palm-springs-struggle-daylight-savings-time-and-idea-sun-time/984416001/
++# Desert Sun, Number 18, 1 November 1946
++# https://cdnc.ucr.edu/cgi-bin/cdnc?a=d&d=DS19461101
++# has proposal for meeting on front page and page 21.
++# Desert Sun, Number 19, 5 November 1946
++# https://cdnc.ucr.edu/cgi-bin/cdnc?a=d&d=DS19461105
++# reports that Sun Time won at the meeting on front page and page 5.
++# Desert Sun, Number 37, 7 January 1947
++# https://cdnc.ucr.edu/cgi-bin/cdnc?a=d&d=DS19470107.2.12
++# front page reports request to abandon Sun Time and page 7 notes a "class war".
++# Desert Sun, Number 38, 10 January 1947
++# https://cdnc.ucr.edu/cgi-bin/cdnc?a=d&d=DS19470110
++# front page reports on end.
++
+ # Argentina
+ # This entry was intended for the following areas, but has been superseded by
+ # more detailed zones.
+@@ -409,7 +443,7 @@
+ # From Paul Eggert (2014-08-21):
+ # In tomorrow's The Hindu, Nitya Menon reports that India had two civil time
+ # zones starting in 1884, one in Bombay and one in Calcutta, and that railways
+-# used a third time zone based on Madras time (80 deg. 18'30" E).  Also,
++# used a third time zone based on Madras time (80° 18' 30" E).  Also,
+ # in 1881 Bombay briefly switched to Madras time, but switched back.  See:
+ # http://www.thehindu.com/news/cities/chennai/madras-375-when-madras-clocked-the-time/article6339393.ece
+ #Zone	  Asia/Chennai  [not enough info to complete]
+@@ -532,7 +566,7 @@
+ # Data from Joseph S. Myers
+ # https://mm.icann.org/pipermail/tz/2013-September/019883.html
+ # References to be added
+-# LMT is for Town Church, St. Peter Port, 49 degrees 27'17"N 2 degrees 32'10"W
++# LMT is for Town Church, St. Peter Port, 49° 27' 17" N, 2° 32' 10" W.
+ Zone	Europe/Guernsey	-0:10:09 -	LMT	1913 Jun 18
+ 			 0:00	GB-Eire	%s	1940 Jul  2
+ 			 1:00	C-Eur	CE%sT	1945 May  8
+@@ -566,7 +600,7 @@
+ # Data from Joseph S. Myers
+ # https://mm.icann.org/pipermail/tz/2013-September/019883.html
+ # References to be added
+-# LMT is for Parish Church, St. Helier, 49 degrees 11'0.57"N 2 degrees 6'24.33"W
++# LMT is for Parish Church, St. Helier, 49° 11' 0.57" N, 2° 6' 24.33" W.
+ Zone	Europe/Jersey	-0:08:26 -	LMT	1898 Jun 11 16:00u
+ 			 0:00	GB-Eire	%s	1940 Jul  2
+ 			 1:00	C-Eur	CE%sT	1945 May  8
+--- contrib/tzdata/checktab.awk.orig
++++ contrib/tzdata/checktab.awk
+@@ -126,6 +126,7 @@
+ 	if ($1 == "Zone") {
+ 		tz = $2
+ 		ruleUsed[$4] = 1
++		if ($5 ~ /%/) rulePercentUsed[$4] = 1
+ 	} else if ($1 == "Link" && zone_table == "zone.tab") {
+ 		# Ignore Link commands if source and destination basenames
+ 		# are identical, e.g. Europe/Istanbul versus Asia/Istanbul.
+@@ -136,8 +137,10 @@
+ 		if (src != dst) tz = $3
+ 	} else if ($1 == "Rule") {
+ 		ruleDefined[$2] = 1
++		if ($10 != "-") ruleLetters[$2] = 1
+ 	} else {
+ 		ruleUsed[$2] = 1
++		if ($3 ~ /%/) rulePercentUsed[$2] = 1
+ 	}
+ 	if (tz && tz ~ /\//) {
+ 		if (!tztab[tz]) {
+@@ -156,6 +159,12 @@
+ 			status = 1
+ 		}
+ 	}
++	for (tz in ruleLetters) {
++		if (!rulePercentUsed[tz]) {
++			printf "%s: Rule contains letters never used\n", tz
++			status = 1
++		}
++	}
+ 	for (tz in tztab) {
+ 		if (!zoneSeen[tz]) {
+ 			printf "%s:%d: no Zone table for '%s'\n", \
+--- contrib/tzdata/europe.orig
++++ contrib/tzdata/europe
+@@ -117,8 +117,8 @@
+ # along the towpath within a few yards of it.'
+ #
+ # I have a one inch to one mile map of London and my estimate of the stone's
+-# position is 51 degrees 28' 30" N, 0 degrees 18' 45" W. The longitude should
+-# be within about +-2". The Ordnance Survey grid reference is TQ172761.
++# position is 51° 28' 30" N, 0° 18' 45" W. The longitude should
++# be within about ±2". The Ordnance Survey grid reference is TQ172761.
+ #
+ # [This yields GMTOFF = -0:01:15 for London LMT in the 18th century.]
+ 
+@@ -158,7 +158,7 @@
+ # after-hours daylight in which to pursue his research.
+ # In 1895 he presented a paper to the Wellington Philosophical Society
+ # that proposed a two-hour daylight-saving shift.  See:
+-# Hudson GV. On seasonal time-adjustment in countries south of lat. 30 deg.
++# Hudson GV. On seasonal time-adjustment in countries south of lat. 30°.
+ # Transactions and Proceedings of the New Zealand Institute. 1895;28:734
+ # http://rsnz.natlib.govt.nz/volume/rsnz_28/rsnz_28_00_006110.html
+ # Although some interest was expressed in New Zealand, his proposal
+@@ -508,11 +508,25 @@
+ Link	Europe/London	Europe/Guernsey
+ Link	Europe/London	Europe/Isle_of_Man
+ 
+-# From Paul Eggert (2018-01-19):
++# From Paul Eggert (2018-02-15):
++# In January 2018 we discovered that the negative SAVE values in the
++# Eire rules cause problems with tests for ICU:
++# https://mm.icann.org/pipermail/tz/2018-January/025825.html
++# and with tests for OpenJDK:
++# https://mm.icann.org/pipermail/tz/2018-January/025822.html
++#
++# To work around this problem, the build procedure can translate the
++# following data into two forms, one with negative SAVE values and the
++# other form with a traditional approximation for Irish time stamps
++# after 1971-10-31 02:00 UTC; although this approximation has tm_isdst
++# flags that are reversed, its UTC offsets are correct and this often
++# suffices.  This source file currently uses only nonnegative SAVE
++# values, but this is intended to change and downstream code should
++# not rely on it.
++#
+ # The following is like GB-Eire and EU, except with standard time in
+-# summer and negative daylight saving time in winter.
+-# Although currently commented out, this will need to become uncommented
+-# once the ICU/OpenJDK workaround is removed; see below.
++# summer and negative daylight saving time in winter.  It is for when
++# negative SAVE values are used.
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+ #Rule	Eire	1971	only	-	Oct	31	 2:00u	-1:00	GMT
+ #Rule	Eire	1972	1980	-	Mar	Sun>=16	 2:00u	0	IST
+@@ -533,24 +547,12 @@
+ 			 0:00	1:00	IST	1947 Nov  2  2:00s
+ 			 0:00	-	GMT	1948 Apr 18  2:00s
+ 			 0:00	GB-Eire	GMT/IST	1968 Oct 27
+-# From Paul Eggert (2018-01-18):
+-# The next line should look like this:
++# The next line is for when negative SAVE values are used.
+ #			 1:00	Eire	IST/GMT
+-# However, in January 2018 we discovered that the Eire rules cause
+-# problems with tests for ICU:
+-# https://mm.icann.org/pipermail/tz/2018-January/025825.html
+-# and with tests for OpenJDK:
+-# https://mm.icann.org/pipermail/tz/2018-January/025822.html
+-# To work around this problem, use a traditional approximation for
+-# time stamps after 1971-10-31 02:00 UTC, to give ICU and OpenJDK
+-# developers breathing room to fix bugs.  This approximation has
+-# correct UTC offsets, but results in tm_isdst flags are the reverse
+-# of what they should be.  This workaround is temporary and should be
+-# removed reasonably soon.
++# These three lines are for when SAVE values are always nonnegative.
+ 			 1:00	-	IST	1971 Oct 31  2:00u
+ 			 0:00	GB-Eire	GMT/IST	1996
+ 			 0:00	EU	GMT/IST
+-# End of workaround for ICU and OpenJDK bugs.
+ 
+ 
+ ###############################################################################
+@@ -1534,21 +1536,21 @@
+ # http://www.almanak.hi.is/klukkan.html
+ #
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Iceland	1917	1919	-	Feb	19	23:00	1:00	S
++Rule	Iceland	1917	1919	-	Feb	19	23:00	1:00	-
+ Rule	Iceland	1917	only	-	Oct	21	 1:00	0	-
+ Rule	Iceland	1918	1919	-	Nov	16	 1:00	0	-
+-Rule	Iceland	1921	only	-	Mar	19	23:00	1:00	S
++Rule	Iceland	1921	only	-	Mar	19	23:00	1:00	-
+ Rule	Iceland	1921	only	-	Jun	23	 1:00	0	-
+-Rule	Iceland	1939	only	-	Apr	29	23:00	1:00	S
++Rule	Iceland	1939	only	-	Apr	29	23:00	1:00	-
+ Rule	Iceland	1939	only	-	Oct	29	 2:00	0	-
+-Rule	Iceland	1940	only	-	Feb	25	 2:00	1:00	S
++Rule	Iceland	1940	only	-	Feb	25	 2:00	1:00	-
+ Rule	Iceland	1940	1941	-	Nov	Sun>=2	 1:00s	0	-
+-Rule	Iceland	1941	1942	-	Mar	Sun>=2	 1:00s	1:00	S
++Rule	Iceland	1941	1942	-	Mar	Sun>=2	 1:00s	1:00	-
+ # 1943-1946 - first Sunday in March until first Sunday in winter
+-Rule	Iceland	1943	1946	-	Mar	Sun>=1	 1:00s	1:00	S
++Rule	Iceland	1943	1946	-	Mar	Sun>=1	 1:00s	1:00	-
+ Rule	Iceland	1942	1948	-	Oct	Sun>=22	 1:00s	0	-
+ # 1947-1967 - first Sunday in April until first Sunday in winter
+-Rule	Iceland	1947	1967	-	Apr	Sun>=1	 1:00s	1:00	S
++Rule	Iceland	1947	1967	-	Apr	Sun>=1	 1:00s	1:00	-
+ # 1949 and 1967 Oct transitions delayed by 1 week
+ Rule	Iceland	1949	only	-	Oct	30	 1:00s	0	-
+ Rule	Iceland	1950	1966	-	Oct	Sun>=22	 1:00s	0	-
+@@ -2138,15 +2140,19 @@
+ 			1:00	EU	CE%sT
+ 
+ # Portugal
+-#
++
+ # From Paul Eggert (2014-08-11), after a heads-up from Stephen Colebourne:
+ # According to a Portuguese decree (1911-05-26)
+ # https://dre.pt/application/dir/pdf1sdip/1911/05/12500/23132313.pdf
+ # Lisbon was at -0:36:44.68, but switched to GMT on 1912-01-01 at 00:00.
+-# Round the old offset to -0:36:45.  This agrees with Willett but disagrees
+-# with Shanks, who says the transition occurred on 1911-05-24 at 00:00 for
+-# Europe/Lisbon, Atlantic/Azores, and Atlantic/Madeira.
++# Round the old offset to -0:36:45.  This agrees with Willett....
+ #
++# From Michael Deckers (2018-02-15):
++# article 5 [of the 1911 decree; Deckers's translation] ...:
++# These dispositions shall enter into force at the instant at which,
++# according to the 2nd article, the civil day January 1, 1912 begins,
++# all clocks therefore having to be advanced or set back correspondingly ...
++
+ # From Rui Pedro Salgueiro (1992-11-12):
+ # Portugal has recently (September, 27) changed timezone
+ # (from WET to MET or CET) to harmonize with EEC.
+@@ -2229,7 +2235,7 @@
+ #
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	Europe/Lisbon	-0:36:45 -	LMT	1884
+-			-0:36:45 -	LMT	1912 Jan  1 # Lisbon Mean Time
++			-0:36:45 -	LMT	1912 Jan  1  0:00u # Lisbon MT
+ 			 0:00	Port	WE%sT	1966 Apr  3  2:00
+ 			 1:00	-	CET	1976 Sep 26  1:00
+ 			 0:00	Port	WE%sT	1983 Sep 25  1:00s
+@@ -2238,7 +2244,7 @@
+ 			 0:00	EU	WE%sT
+ # This Zone can be simplified once we assume zic %z.
+ Zone Atlantic/Azores	-1:42:40 -	LMT	1884        # Ponta Delgada
+-			-1:54:32 -	HMT	1912 Jan  1 # Horta Mean Time
++			-1:54:32 -	HMT	1912 Jan  1  2:00u # Horta MT
+ 			-2:00	Port	-02/-01	1942 Apr 25 22:00s
+ 			-2:00	Port	+00	1942 Aug 15 22:00s
+ 			-2:00	Port	-02/-01	1943 Apr 17 22:00s
+@@ -2254,7 +2260,7 @@
+ 			-1:00	EU	-01/+00
+ # This Zone can be simplified once we assume zic %z.
+ Zone Atlantic/Madeira	-1:07:36 -	LMT	1884        # Funchal
+-			-1:07:36 -	FMT	1912 Jan  1 # Funchal Mean Time
++			-1:07:36 -	FMT	1912 Jan  1  1:00u # Funchal MT
+ 			-1:00	Port	-01/+00	1942 Apr 25 22:00s
+ 			-1:00	Port	+01	1942 Aug 15 22:00s
+ 			-1:00	Port	-01/+00	1943 Apr 17 22:00s
+@@ -2592,13 +2598,13 @@
+ 
+ # From Vladimir Karpinsky (2014-07-08):
+ # LMT in Moscow (before Jul 3, 1916) is 2:30:17, that was defined by Moscow
+-# Observatory (coordinates: 55 deg. 45'29.70", 37 deg. 34'05.30")....
++# Observatory (coordinates: 55° 45' 29.70", 37° 34' 05.30")....
+ # LMT in Moscow since Jul 3, 1916 is 2:31:01 as a result of new standard.
+ # (The info is from the book by Byalokoz ... p. 18.)
+ # The time in St. Petersburg as capital of Russia was defined by
+ # Pulkov observatory, near St. Petersburg.  In 1916 LMT Moscow
+ # was synchronized with LMT St. Petersburg (+30 minutes), (Pulkov observatory
+-# coordinates: 59 deg. 46'18.70", 30 deg. 19'40.70") so 30 deg. 19'40.70" >
++# coordinates: 59° 46' 18.70", 30° 19' 40.70") so 30° 19' 40.70" >
+ # 2h01m18.7s = 2:01:19.  LMT Moscow = LMT St.Petersburg + 30m 2:01:19 + 0:30 =
+ # 2:31:19 ...
+ #
+@@ -3427,7 +3433,7 @@
+ # three degrees, or twelve minutes of time, to the west of the
+ # meridian of the Observatory of Stockholm".  The law is dated 1878-05-31.
+ #
+-# The observatory at that time had the meridian 18 degrees 03' 30"
++# The observatory at that time had the meridian 18° 03' 30"
+ # eastern longitude = 01:12:14 in time.  Less 12 minutes gives the
+ # national standard time as 01:00:14 ahead of GMT....
+ #
+@@ -3531,7 +3537,7 @@
+ # From Alois Treindl (2013-09-11):
+ # The Federal regulations say
+ # https://www.admin.ch/opc/de/classified-compilation/20071096/index.html
+-# ... the meridian for Bern mean time ... is 7 degrees 26' 22.50".
++# ... the meridian for Bern mean time ... is 7° 26' 22.50".
+ # Expressed in time, it is 0h29m45.5s.
+ 
+ # From Pierre-Yves Berger (2013-09-11):
+--- contrib/tzdata/northamerica.orig
++++ contrib/tzdata/northamerica
+@@ -25,7 +25,7 @@
+ # in New York City (1869-10).  His 1870 proposal was based on Washington, DC,
+ # but in 1872-05 he moved the proposed origin to Greenwich.
+ 
+-# From Paul Eggert (2016-09-21):
++# From Paul Eggert (2018-03-20):
+ # Dowd's proposal left many details unresolved, such as where to draw
+ # lines between time zones.  The key individual who made time zones
+ # work in the US was William Frederick Allen - railway engineer,
+@@ -36,10 +36,9 @@
+ # to the General Time Convention on 1883-04-11, saying that his plan
+ # meant "local time would be practically abolished" - a plus for
+ # railway scheduling.  By the next convention on 1883-10-11 nearly all
+-# railroads had agreed and it took effect on 1883-11-18 at 12:00.
+-# That Sunday was called the "day of two noons", as the eastern parts
+-# of the new zones observed noon twice.  Allen witnessed the
+-# transition in New York City, writing:
++# railroads had agreed and it took effect on 1883-11-18.  That Sunday
++# was called the "day of two noons", as some locations observed noon
++# twice.  Allen witnessed the transition in New York City, writing:
+ #
+ #   I heard the bells of St. Paul's strike on the old time.  Four
+ #   minutes later, obedient to the electrical signal from the Naval
+@@ -424,8 +423,7 @@
+ # ...according to the Census Bureau, the largest city is Beulah (although
+ # it's commonly referred to as Beulah-Hazen, with Hazen being the next
+ # largest city in Mercer County).  Google Maps places Beulah's city hall
+-# at 47 degrees 15' 51" N, 101 degrees 46' 40" W, which yields an offset
+-# of 6h47'07".
++# at 47° 15' 51" N, 101° 46' 40" W, which yields an offset of 6h47'07".
+ 
+ Zone America/North_Dakota/Beulah -6:47:07 - LMT	1883 Nov 18 12:12:53
+ 			-7:00	US	M%sT	2010 Nov  7  2:00
+@@ -458,7 +456,7 @@
+ # California, northern Idaho (Benewah, Bonner, Boundary, Clearwater,
+ # Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, Idaho county
+ # north of the Salmon River, and the towns of Burgdorf and Warren),
+-# Nevada (except West Wendover), Oregon (except the northern 3/4 of
++# Nevada (except West Wendover), Oregon (except the northern ¾ of
+ # Malheur county), and Washington
+ 
+ # From Paul Eggert (2016-08-20):
+@@ -956,6 +954,13 @@
+ 			-5:00	-	EST	2006
+ 			-5:00	US	E%sT
+ 
++# From Paul Eggert (2018-03-20):
++# The Louisville & Nashville Railroad's 1883-11-18 change occurred at
++# 10:00 old local time; train were supposed to come to a standstill
++# for precisely 18 minutes.  See Bartky Fig. 1 (page 50).  It is not
++# clear how this matched civil time in Louisville, so for now continue
++# to assume Louisville switched at noon new local time, like New York.
++#
+ # Part of Kentucky left its clocks alone in 1974.
+ # This also includes Clark, Floyd, and Harrison counties in Indiana.
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER
+@@ -3264,8 +3269,8 @@
+ # http://www.jamaicaobserver.com/columns/The-politician-in-all-of-us_17573647
+ #
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+-Zone	America/Jamaica	-5:07:11 -	LMT	1890        # Kingston
+-			-5:07:11 -	KMT	1912 Feb    # Kingston Mean Time
++Zone	America/Jamaica	-5:07:10 -	LMT	1890        # Kingston
++			-5:07:10 -	KMT	1912 Feb    # Kingston Mean Time
+ 			-5:00	-	EST	1974
+ 			-5:00	US	E%sT	1984
+ 			-5:00	-	EST
+@@ -3415,7 +3420,7 @@
+ #
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone America/Grand_Turk	-4:44:32 -	LMT	1890
+-			-5:07:11 -	KMT	1912 Feb # Kingston Mean Time
++			-5:07:10 -	KMT	1912 Feb # Kingston Mean Time
+ 			-5:00	-	EST	1979
+ 			-5:00	US	E%sT	2015 Nov Sun>=1 2:00
+ 			-4:00	-	AST	2018 Mar 11 3:00
+--- contrib/tzdata/southamerica.orig
++++ contrib/tzdata/southamerica
+@@ -47,28 +47,28 @@
+ # AR was chosen because they are the ISO letters that represent Argentina.
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Arg	1930	only	-	Dec	 1	0:00	1:00	S
++Rule	Arg	1930	only	-	Dec	 1	0:00	1:00	-
+ Rule	Arg	1931	only	-	Apr	 1	0:00	0	-
+-Rule	Arg	1931	only	-	Oct	15	0:00	1:00	S
++Rule	Arg	1931	only	-	Oct	15	0:00	1:00	-
+ Rule	Arg	1932	1940	-	Mar	 1	0:00	0	-
+-Rule	Arg	1932	1939	-	Nov	 1	0:00	1:00	S
+-Rule	Arg	1940	only	-	Jul	 1	0:00	1:00	S
++Rule	Arg	1932	1939	-	Nov	 1	0:00	1:00	-
++Rule	Arg	1940	only	-	Jul	 1	0:00	1:00	-
+ Rule	Arg	1941	only	-	Jun	15	0:00	0	-
+-Rule	Arg	1941	only	-	Oct	15	0:00	1:00	S
++Rule	Arg	1941	only	-	Oct	15	0:00	1:00	-
+ Rule	Arg	1943	only	-	Aug	 1	0:00	0	-
+-Rule	Arg	1943	only	-	Oct	15	0:00	1:00	S
++Rule	Arg	1943	only	-	Oct	15	0:00	1:00	-
+ Rule	Arg	1946	only	-	Mar	 1	0:00	0	-
+-Rule	Arg	1946	only	-	Oct	 1	0:00	1:00	S
++Rule	Arg	1946	only	-	Oct	 1	0:00	1:00	-
+ Rule	Arg	1963	only	-	Oct	 1	0:00	0	-
+-Rule	Arg	1963	only	-	Dec	15	0:00	1:00	S
++Rule	Arg	1963	only	-	Dec	15	0:00	1:00	-
+ Rule	Arg	1964	1966	-	Mar	 1	0:00	0	-
+-Rule	Arg	1964	1966	-	Oct	15	0:00	1:00	S
++Rule	Arg	1964	1966	-	Oct	15	0:00	1:00	-
+ Rule	Arg	1967	only	-	Apr	 2	0:00	0	-
+-Rule	Arg	1967	1968	-	Oct	Sun>=1	0:00	1:00	S
++Rule	Arg	1967	1968	-	Oct	Sun>=1	0:00	1:00	-
+ Rule	Arg	1968	1969	-	Apr	Sun>=1	0:00	0	-
+-Rule	Arg	1974	only	-	Jan	23	0:00	1:00	S
++Rule	Arg	1974	only	-	Jan	23	0:00	1:00	-
+ Rule	Arg	1974	only	-	May	 1	0:00	0	-
+-Rule	Arg	1988	only	-	Dec	 1	0:00	1:00	S
++Rule	Arg	1988	only	-	Dec	 1	0:00	1:00	-
+ #
+ # From Hernan G. Otero (1995-06-26):
+ # These corrections were contributed by InterSoft Argentina S.A.,
+@@ -76,7 +76,7 @@
+ # Talleres de Hidrografía Naval Argentina
+ # (Argentine Naval Hydrography Institute)
+ Rule	Arg	1989	1993	-	Mar	Sun>=1	0:00	0	-
+-Rule	Arg	1989	1992	-	Oct	Sun>=15	0:00	1:00	S
++Rule	Arg	1989	1992	-	Oct	Sun>=15	0:00	1:00	-
+ #
+ # From Hernan G. Otero (1995-06-26):
+ # From this moment on, the law that mandated the daylight saving
+@@ -87,7 +87,7 @@
+ # On October 3, 1999, 0:00 local, Argentina implemented daylight savings time,
+ # which did not result in the switch of a time zone, as they stayed 9 hours
+ # from the International Date Line.
+-Rule	Arg	1999	only	-	Oct	Sun>=1	0:00	1:00	S
++Rule	Arg	1999	only	-	Oct	Sun>=1	0:00	1:00	-
+ # From Paul Eggert (2007-12-28):
+ # DST was set to expire on March 5, not March 3, but since it was converted
+ # to standard time on March 3 it's more convenient for us to pretend that
+@@ -190,9 +190,9 @@
+ # la modificación del huso horario, ya que 2009 nos encuentra con
+ # crecimiento en la producción y distribución energética."
+ 
+-Rule	Arg	2007	only	-	Dec	30	0:00	1:00	S
++Rule	Arg	2007	only	-	Dec	30	0:00	1:00	-
+ Rule	Arg	2008	2009	-	Mar	Sun>=15	0:00	0	-
+-Rule	Arg	2008	only	-	Oct	Sun>=15	0:00	1:00	S
++Rule	Arg	2008	only	-	Oct	Sun>=15	0:00	1:00	-
+ 
+ # From Mariano Absatz (2004-05-21):
+ # Today it was officially published that the Province of Mendoza is changing
+@@ -202,12 +202,14 @@
+ # It's Law No. 7,210.  This change is due to a public power emergency, so for
+ # now we'll assume it's for this year only.
+ #
+-# From Paul Eggert (2014-08-09):
++# From Paul Eggert (2018-01-31):
+ # Hora de verano para la República Argentina
+ # http://buenasiembra.com.ar/esoterismo/astrologia/hora-de-verano-de-la-republica-argentina-27.html
+ # says that standard time in Argentina from 1894-10-31
+ # to 1920-05-01 was -4:16:48.25.  Go with this more-precise value
+-# over Shanks & Pottenger.
++# over Shanks & Pottenger.  It is upward compatible with Milne, who
++# says Córdoba time was -4:16:48.2.
++
+ #
+ # From Mariano Absatz (2004-06-05):
+ # These media articles from a major newspaper mostly cover the current state:
+@@ -381,9 +383,9 @@
+ # rules...San Luis is still using "Western ARgentina Time" and it got
+ # stuck on Summer daylight savings time even though the summer is over.
+ 
+-# From Paul Eggert (2013-09-05):
++# From Paul Eggert (2018-01-23):
+ # Perhaps San Luis operates on the legal fiction that it is at -04
+-# with perpetual summer time, but ordinary usage typically seems to
++# with perpetual daylight saving time, but ordinary usage typically seems to
+ # just say it's at -03; see, for example,
+ # https://es.wikipedia.org/wiki/Hora_oficial_argentina
+ # We've documented similar situations as being plain changes to
+@@ -392,9 +394,6 @@
+ # plus is that this silences a zic complaint that there's no POSIX TZ
+ # setting for time stamps past 2038.
+ 
+-# From Paul Eggert (2013-02-21):
+-# Milne says Córdoba time was -4:16:48.2.  Round to the nearest second.
+-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ #
+ # Buenos Aires (BA), Capital Federal (CF),
+@@ -529,7 +528,7 @@
+ # San Luis (SL)
+ 
+ Rule	SanLuis	2008	2009	-	Mar	Sun>=8	0:00	0	-
+-Rule	SanLuis	2007	2008	-	Oct	Sun>=8	0:00	1:00	S
++Rule	SanLuis	2007	2008	-	Oct	Sun>=8	0:00	1:00	-
+ 
+ Zone America/Argentina/San_Luis -4:25:24 - LMT	1894 Oct 31
+ 			-4:16:48 -	CMT	1920 May
+@@ -771,14 +770,14 @@
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+ # Decree 20,466 <http://pcdsh01.on.br/HV20466.htm> (1931-10-01)
+ # Decree 21,896 <http://pcdsh01.on.br/HV21896.htm> (1932-01-10)
+-Rule	Brazil	1931	only	-	Oct	 3	11:00	1:00	S
++Rule	Brazil	1931	only	-	Oct	 3	11:00	1:00	-
+ Rule	Brazil	1932	1933	-	Apr	 1	 0:00	0	-
+-Rule	Brazil	1932	only	-	Oct	 3	 0:00	1:00	S
++Rule	Brazil	1932	only	-	Oct	 3	 0:00	1:00	-
+ # Decree 23,195 <http://pcdsh01.on.br/HV23195.htm> (1933-10-10)
+ # revoked DST.
+ # Decree 27,496 <http://pcdsh01.on.br/HV27496.htm> (1949-11-24)
+ # Decree 27,998 <http://pcdsh01.on.br/HV27998.htm> (1950-04-13)
+-Rule	Brazil	1949	1952	-	Dec	 1	 0:00	1:00	S
++Rule	Brazil	1949	1952	-	Dec	 1	 0:00	1:00	-
+ Rule	Brazil	1950	only	-	Apr	16	 1:00	0	-
+ Rule	Brazil	1951	1952	-	Apr	 1	 0:00	0	-
+ # Decree 32,308 <http://pcdsh01.on.br/HV32308.htm> (1953-02-24)
+@@ -790,51 +789,51 @@
+ # in SP, RJ, GB, MG, ES, due to the prolongation of the drought.
+ # Decree 53,071 <http://pcdsh01.on.br/HV53071.htm> (1963-12-03)
+ # extended the above decree to all of the national territory on 12-09.
+-Rule	Brazil	1963	only	-	Dec	 9	 0:00	1:00	S
++Rule	Brazil	1963	only	-	Dec	 9	 0:00	1:00	-
+ # Decree 53,604 <http://pcdsh01.on.br/HV53604.htm> (1964-02-25)
+ # extended summer time by one day to 1964-03-01 00:00 (start of school).
+ Rule	Brazil	1964	only	-	Mar	 1	 0:00	0	-
+ # Decree 55,639 <http://pcdsh01.on.br/HV55639.htm> (1965-01-27)
+-Rule	Brazil	1965	only	-	Jan	31	 0:00	1:00	S
++Rule	Brazil	1965	only	-	Jan	31	 0:00	1:00	-
+ Rule	Brazil	1965	only	-	Mar	31	 0:00	0	-
+ # Decree 57,303 <http://pcdsh01.on.br/HV57303.htm> (1965-11-22)
+-Rule	Brazil	1965	only	-	Dec	 1	 0:00	1:00	S
++Rule	Brazil	1965	only	-	Dec	 1	 0:00	1:00	-
+ # Decree 57,843 <http://pcdsh01.on.br/HV57843.htm> (1966-02-18)
+ Rule	Brazil	1966	1968	-	Mar	 1	 0:00	0	-
+-Rule	Brazil	1966	1967	-	Nov	 1	 0:00	1:00	S
++Rule	Brazil	1966	1967	-	Nov	 1	 0:00	1:00	-
+ # Decree 63,429 <http://pcdsh01.on.br/HV63429.htm> (1968-10-15)
+ # revoked DST.
+ # Decree 91,698 <http://pcdsh01.on.br/HV91698.htm> (1985-09-27)
+-Rule	Brazil	1985	only	-	Nov	 2	 0:00	1:00	S
++Rule	Brazil	1985	only	-	Nov	 2	 0:00	1:00	-
+ # Decree 92,310 (1986-01-21)
+ # Decree 92,463 (1986-03-13)
+ Rule	Brazil	1986	only	-	Mar	15	 0:00	0	-
+ # Decree 93,316 (1986-10-01)
+-Rule	Brazil	1986	only	-	Oct	25	 0:00	1:00	S
++Rule	Brazil	1986	only	-	Oct	25	 0:00	1:00	-
+ Rule	Brazil	1987	only	-	Feb	14	 0:00	0	-
+ # Decree 94,922 <http://pcdsh01.on.br/HV94922.htm> (1987-09-22)
+-Rule	Brazil	1987	only	-	Oct	25	 0:00	1:00	S
++Rule	Brazil	1987	only	-	Oct	25	 0:00	1:00	-
+ Rule	Brazil	1988	only	-	Feb	 7	 0:00	0	-
+ # Decree 96,676 <http://pcdsh01.on.br/HV96676.htm> (1988-09-12)
+ # except for the states of AC, AM, PA, RR, RO, and AP (then a territory)
+-Rule	Brazil	1988	only	-	Oct	16	 0:00	1:00	S
++Rule	Brazil	1988	only	-	Oct	16	 0:00	1:00	-
+ Rule	Brazil	1989	only	-	Jan	29	 0:00	0	-
+ # Decree 98,077 <http://pcdsh01.on.br/HV98077.htm> (1989-08-21)
+ # with the same exceptions
+-Rule	Brazil	1989	only	-	Oct	15	 0:00	1:00	S
++Rule	Brazil	1989	only	-	Oct	15	 0:00	1:00	-
+ Rule	Brazil	1990	only	-	Feb	11	 0:00	0	-
+ # Decree 99,530 <http://pcdsh01.on.br/HV99530.htm> (1990-09-17)
+ # adopted by RS, SC, PR, SP, RJ, ES, MG, GO, MS, DF.
+ # Decree 99,629 (1990-10-19) adds BA, MT.
+-Rule	Brazil	1990	only	-	Oct	21	 0:00	1:00	S
++Rule	Brazil	1990	only	-	Oct	21	 0:00	1:00	-
+ Rule	Brazil	1991	only	-	Feb	17	 0:00	0	-
+ # Unnumbered decree <http://pcdsh01.on.br/HV1991.htm> (1991-09-25)
+ # adopted by RS, SC, PR, SP, RJ, ES, MG, BA, GO, MT, MS, DF.
+-Rule	Brazil	1991	only	-	Oct	20	 0:00	1:00	S
++Rule	Brazil	1991	only	-	Oct	20	 0:00	1:00	-
+ Rule	Brazil	1992	only	-	Feb	 9	 0:00	0	-
+ # Unnumbered decree <http://pcdsh01.on.br/HV1992.htm> (1992-10-16)
+ # adopted by same states.
+-Rule	Brazil	1992	only	-	Oct	25	 0:00	1:00	S
++Rule	Brazil	1992	only	-	Oct	25	 0:00	1:00	-
+ Rule	Brazil	1993	only	-	Jan	31	 0:00	0	-
+ # Decree 942 <http://pcdsh01.on.br/HV942.htm> (1993-09-28)
+ # adopted by same states, plus AM.
+@@ -844,12 +843,12 @@
+ # adopted by same states, plus MT and TO.
+ # Decree 1,674 <http://pcdsh01.on.br/HV1674.htm> (1995-10-13)
+ # adds AL, SE.
+-Rule	Brazil	1993	1995	-	Oct	Sun>=11	 0:00	1:00	S
++Rule	Brazil	1993	1995	-	Oct	Sun>=11	 0:00	1:00	-
+ Rule	Brazil	1994	1995	-	Feb	Sun>=15	 0:00	0	-
+ Rule	Brazil	1996	only	-	Feb	11	 0:00	0	-
+ # Decree 2,000 <http://pcdsh01.on.br/HV2000.htm> (1996-09-04)
+ # adopted by same states, minus AL, SE.
+-Rule	Brazil	1996	only	-	Oct	 6	 0:00	1:00	S
++Rule	Brazil	1996	only	-	Oct	 6	 0:00	1:00	-
+ Rule	Brazil	1997	only	-	Feb	16	 0:00	0	-
+ # From Daniel C. Sobral (1998-02-12):
+ # In 1997, the DS began on October 6. The stated reason was that
+@@ -859,19 +858,19 @@
+ # to help dealing with the shortages of electric power.
+ #
+ # Decree 2,317 (1997-09-04), adopted by same states.
+-Rule	Brazil	1997	only	-	Oct	 6	 0:00	1:00	S
++Rule	Brazil	1997	only	-	Oct	 6	 0:00	1:00	-
+ # Decree 2,495 <http://pcdsh01.on.br/figuras/HV2495.JPG>
+ # (1998-02-10)
+ Rule	Brazil	1998	only	-	Mar	 1	 0:00	0	-
+ # Decree 2,780 <http://pcdsh01.on.br/figuras/Hv98.jpg> (1998-09-11)
+ # adopted by the same states as before.
+-Rule	Brazil	1998	only	-	Oct	11	 0:00	1:00	S
++Rule	Brazil	1998	only	-	Oct	11	 0:00	1:00	-
+ Rule	Brazil	1999	only	-	Feb	21	 0:00	0	-
+ # Decree 3,150 <http://pcdsh01.on.br/figuras/HV3150.gif>
+ # (1999-08-23) adopted by same states.
+ # Decree 3,188 <http://pcdsh01.on.br/DecHV99.gif> (1999-09-30)
+ # adds SE, AL, PB, PE, RN, CE, PI, MA and RR.
+-Rule	Brazil	1999	only	-	Oct	 3	 0:00	1:00	S
++Rule	Brazil	1999	only	-	Oct	 3	 0:00	1:00	-
+ Rule	Brazil	2000	only	-	Feb	27	 0:00	0	-
+ # Decree 3,592 <http://pcdsh01.on.br/DEC3592.htm> (2000-09-06)
+ # adopted by the same states as before.
+@@ -881,27 +880,27 @@
+ # repeals DST in SE, AL, PB, RN, CE, PI and MA, effective 2000-10-22 00:00.
+ # Decree 3,916 <http://pcdsh01.on.br/figuras/HV3916.gif>
+ # (2001-09-13) reestablishes DST in AL, CE, MA, PB, PE, PI, RN, SE.
+-Rule	Brazil	2000	2001	-	Oct	Sun>=8	 0:00	1:00	S
++Rule	Brazil	2000	2001	-	Oct	Sun>=8	 0:00	1:00	-
+ Rule	Brazil	2001	2006	-	Feb	Sun>=15	 0:00	0	-
+ # Decree 4,399 (2002-10-01) repeals DST in AL, CE, MA, PB, PE, PI, RN, SE.
+ # 4,399 <http://www.presidencia.gov.br/CCIVIL/decreto/2002/D4399.htm>
+-Rule	Brazil	2002	only	-	Nov	 3	 0:00	1:00	S
++Rule	Brazil	2002	only	-	Nov	 3	 0:00	1:00	-
+ # Decree 4,844 (2003-09-24; corrected 2003-09-26) repeals DST in BA, MT, TO.
+ # 4,844 <http://www.presidencia.gov.br/CCIVIL/decreto/2003/D4844.htm>
+-Rule	Brazil	2003	only	-	Oct	19	 0:00	1:00	S
++Rule	Brazil	2003	only	-	Oct	19	 0:00	1:00	-
+ # Decree 5,223 (2004-10-01) reestablishes DST in MT.
+ # 5,223 <http://www.planalto.gov.br/ccivil_03/_Ato2004-2006/2004/Decreto/D5223.htm>
+-Rule	Brazil	2004	only	-	Nov	 2	 0:00	1:00	S
++Rule	Brazil	2004	only	-	Nov	 2	 0:00	1:00	-
+ # Decree 5,539 <http://pcdsh01.on.br/DecHV5539.gif> (2005-09-19),
+ # adopted by the same states as before.
+-Rule	Brazil	2005	only	-	Oct	16	 0:00	1:00	S
++Rule	Brazil	2005	only	-	Oct	16	 0:00	1:00	-
+ # Decree 5,920 <http://pcdsh01.on.br/DecHV5920.gif> (2006-10-03),
+ # adopted by the same states as before.
+-Rule	Brazil	2006	only	-	Nov	 5	 0:00	1:00	S
++Rule	Brazil	2006	only	-	Nov	 5	 0:00	1:00	-
+ Rule	Brazil	2007	only	-	Feb	25	 0:00	0	-
+ # Decree 6,212 <http://pcdsh01.on.br/DecHV6212.gif> (2007-09-26),
+ # adopted by the same states as before.
+-Rule	Brazil	2007	only	-	Oct	Sun>=8	 0:00	1:00	S
++Rule	Brazil	2007	only	-	Oct	Sun>=8	 0:00	1:00	-
+ # From Frederico A. C. Neves (2008-09-10):
+ # According to this decree
+ # http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm
+@@ -908,7 +907,7 @@
+ # [t]he DST period in Brazil now on will be from the 3rd Oct Sunday to the
+ # 3rd Feb Sunday. There is an exception on the return date when this is
+ # the Carnival Sunday then the return date will be the next Sunday...
+-Rule	Brazil	2008	2017	-	Oct	Sun>=15	0:00	1:00	S
++Rule	Brazil	2008	2017	-	Oct	Sun>=15	0:00	1:00	-
+ Rule	Brazil	2008	2011	-	Feb	Sun>=15	0:00	0	-
+ # Decree 7,584 <http://pcdsh01.on.br/HVdecreto7584_20111013.jpg> (2011-10-13)
+ # added Bahia.
+@@ -926,7 +925,7 @@
+ # ... https://www.timeanddate.com/news/time/brazil-delays-dst-2018.html
+ # From Steffen Thorsen (2017-12-20):
+ # http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2017/decreto/D9242.htm
+-Rule	Brazil	2018	max	-	Nov	Sun>=1	0:00	1:00	S
++Rule	Brazil	2018	max	-	Nov	Sun>=1	0:00	1:00	-
+ Rule	Brazil	2023	only	-	Feb	Sun>=22	0:00	0	-
+ Rule	Brazil	2024	2025	-	Feb	Sun>=15	0:00	0	-
+ Rule	Brazil	2026	only	-	Feb	Sun>=22	0:00	0	-
+@@ -1233,28 +1232,28 @@
+ # For now, assume that they will not revert.
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Chile	1927	1931	-	Sep	 1	0:00	1:00	S
++Rule	Chile	1927	1931	-	Sep	 1	0:00	1:00	-
+ Rule	Chile	1928	1932	-	Apr	 1	0:00	0	-
+-Rule	Chile	1968	only	-	Nov	 3	4:00u	1:00	S
++Rule	Chile	1968	only	-	Nov	 3	4:00u	1:00	-
+ Rule	Chile	1969	only	-	Mar	30	3:00u	0	-
+-Rule	Chile	1969	only	-	Nov	23	4:00u	1:00	S
++Rule	Chile	1969	only	-	Nov	23	4:00u	1:00	-
+ Rule	Chile	1970	only	-	Mar	29	3:00u	0	-
+ Rule	Chile	1971	only	-	Mar	14	3:00u	0	-
+-Rule	Chile	1970	1972	-	Oct	Sun>=9	4:00u	1:00	S
++Rule	Chile	1970	1972	-	Oct	Sun>=9	4:00u	1:00	-
+ Rule	Chile	1972	1986	-	Mar	Sun>=9	3:00u	0	-
+-Rule	Chile	1973	only	-	Sep	30	4:00u	1:00	S
+-Rule	Chile	1974	1987	-	Oct	Sun>=9	4:00u	1:00	S
++Rule	Chile	1973	only	-	Sep	30	4:00u	1:00	-
++Rule	Chile	1974	1987	-	Oct	Sun>=9	4:00u	1:00	-
+ Rule	Chile	1987	only	-	Apr	12	3:00u	0	-
+ Rule	Chile	1988	1990	-	Mar	Sun>=9	3:00u	0	-
+-Rule	Chile	1988	1989	-	Oct	Sun>=9	4:00u	1:00	S
+-Rule	Chile	1990	only	-	Sep	16	4:00u	1:00	S
++Rule	Chile	1988	1989	-	Oct	Sun>=9	4:00u	1:00	-
++Rule	Chile	1990	only	-	Sep	16	4:00u	1:00	-
+ Rule	Chile	1991	1996	-	Mar	Sun>=9	3:00u	0	-
+-Rule	Chile	1991	1997	-	Oct	Sun>=9	4:00u	1:00	S
++Rule	Chile	1991	1997	-	Oct	Sun>=9	4:00u	1:00	-
+ Rule	Chile	1997	only	-	Mar	30	3:00u	0	-
+ Rule	Chile	1998	only	-	Mar	Sun>=9	3:00u	0	-
+-Rule	Chile	1998	only	-	Sep	27	4:00u	1:00	S
++Rule	Chile	1998	only	-	Sep	27	4:00u	1:00	-
+ Rule	Chile	1999	only	-	Apr	 4	3:00u	0	-
+-Rule	Chile	1999	2010	-	Oct	Sun>=9	4:00u	1:00	S
++Rule	Chile	1999	2010	-	Oct	Sun>=9	4:00u	1:00	-
+ Rule	Chile	2000	2007	-	Mar	Sun>=9	3:00u	0	-
+ # N.B.: the end of March 29 in Chile is March 30 in Universal time,
+ # which is used below in specifying the transition.
+@@ -1262,11 +1261,11 @@
+ Rule	Chile	2009	only	-	Mar	Sun>=9	3:00u	0	-
+ Rule	Chile	2010	only	-	Apr	Sun>=1	3:00u	0	-
+ Rule	Chile	2011	only	-	May	Sun>=2	3:00u	0	-
+-Rule	Chile	2011	only	-	Aug	Sun>=16	4:00u	1:00	S
++Rule	Chile	2011	only	-	Aug	Sun>=16	4:00u	1:00	-
+ Rule	Chile	2012	2014	-	Apr	Sun>=23	3:00u	0	-
+-Rule	Chile	2012	2014	-	Sep	Sun>=2	4:00u	1:00	S
++Rule	Chile	2012	2014	-	Sep	Sun>=2	4:00u	1:00	-
+ Rule	Chile	2016	max	-	May	Sun>=9	3:00u	0	-
+-Rule	Chile	2016	max	-	Aug	Sun>=9	4:00u	1:00	S
++Rule	Chile	2016	max	-	Aug	Sun>=9	4:00u	1:00	-
+ # IATA SSIM anomalies: (1992-02) says 1992-03-14;
+ # (1996-09) says 1998-03-08.  Ignore these.
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+@@ -1331,7 +1330,7 @@
+ # "A variation of fifteen minutes in the public clocks of Bogota is not rare."
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	CO	1992	only	-	May	 3	0:00	1:00	S
++Rule	CO	1992	only	-	May	 3	0:00	1:00	-
+ Rule	CO	1993	only	-	Apr	 4	0:00	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	America/Bogota	-4:56:16 -	LMT	1884 Mar 13
+@@ -1391,7 +1390,7 @@
+ # repeated.  For now, assume transitions were at 00:00 local time country-wide.
+ #
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Ecuador	1992	only	-	Nov	28	0:00	1:00	S
++Rule	Ecuador	1992	only	-	Nov	28	0:00	1:00	-
+ Rule	Ecuador	1993	only	-	Feb	 5	0:00	0	-
+ #
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+@@ -1481,22 +1480,22 @@
+ #   the maintainers of the database to inform them we're adopting
+ #   the same policy this year and suggest recommendations for future years.
+ #
+-# For now we will assume permanent summer time for the Falklands
++# For now we will assume permanent -03 for the Falklands
+ # until advised differently (to apply for 2012 and beyond, after the 2011
+ # experiment was apparently successful.)
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Falk	1937	1938	-	Sep	lastSun	0:00	1:00	S
++Rule	Falk	1937	1938	-	Sep	lastSun	0:00	1:00	-
+ Rule	Falk	1938	1942	-	Mar	Sun>=19	0:00	0	-
+-Rule	Falk	1939	only	-	Oct	1	0:00	1:00	S
+-Rule	Falk	1940	1942	-	Sep	lastSun	0:00	1:00	S
++Rule	Falk	1939	only	-	Oct	1	0:00	1:00	-
++Rule	Falk	1940	1942	-	Sep	lastSun	0:00	1:00	-
+ Rule	Falk	1943	only	-	Jan	1	0:00	0	-
+-Rule	Falk	1983	only	-	Sep	lastSun	0:00	1:00	S
++Rule	Falk	1983	only	-	Sep	lastSun	0:00	1:00	-
+ Rule	Falk	1984	1985	-	Apr	lastSun	0:00	0	-
+-Rule	Falk	1984	only	-	Sep	16	0:00	1:00	S
+-Rule	Falk	1985	2000	-	Sep	Sun>=9	0:00	1:00	S
++Rule	Falk	1984	only	-	Sep	16	0:00	1:00	-
++Rule	Falk	1985	2000	-	Sep	Sun>=9	0:00	1:00	-
+ Rule	Falk	1986	2000	-	Apr	Sun>=16	0:00	0	-
+ Rule	Falk	2001	2010	-	Apr	Sun>=15	2:00	0	-
+-Rule	Falk	2001	2010	-	Sep	Sun>=1	2:00	1:00	S
++Rule	Falk	2001	2010	-	Sep	Sun>=1	2:00	1:00	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone Atlantic/Stanley	-3:51:24 -	LMT	1890
+ 			-3:51:24 -	SMT	1912 Mar 12 # Stanley Mean Time
+@@ -1531,16 +1530,16 @@
+ # adjust their clocks at 0 hour of the given dates.
+ #
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Para	1975	1988	-	Oct	 1	0:00	1:00	S
++Rule	Para	1975	1988	-	Oct	 1	0:00	1:00	-
+ Rule	Para	1975	1978	-	Mar	 1	0:00	0	-
+ Rule	Para	1979	1991	-	Apr	 1	0:00	0	-
+-Rule	Para	1989	only	-	Oct	22	0:00	1:00	S
+-Rule	Para	1990	only	-	Oct	 1	0:00	1:00	S
+-Rule	Para	1991	only	-	Oct	 6	0:00	1:00	S
++Rule	Para	1989	only	-	Oct	22	0:00	1:00	-
++Rule	Para	1990	only	-	Oct	 1	0:00	1:00	-
++Rule	Para	1991	only	-	Oct	 6	0:00	1:00	-
+ Rule	Para	1992	only	-	Mar	 1	0:00	0	-
+-Rule	Para	1992	only	-	Oct	 5	0:00	1:00	S
++Rule	Para	1992	only	-	Oct	 5	0:00	1:00	-
+ Rule	Para	1993	only	-	Mar	31	0:00	0	-
+-Rule	Para	1993	1995	-	Oct	 1	0:00	1:00	S
++Rule	Para	1993	1995	-	Oct	 1	0:00	1:00	-
+ Rule	Para	1994	1995	-	Feb	lastSun	0:00	0	-
+ Rule	Para	1996	only	-	Mar	 1	0:00	0	-
+ # IATA SSIM (2000-02) says 1999-10-10; ignore this for now.
+@@ -1558,7 +1557,7 @@
+ # year, the time will change on the first Sunday of October; likewise, the
+ # clock will be set back on the first Sunday of March.
+ #
+-Rule	Para	1996	2001	-	Oct	Sun>=1	0:00	1:00	S
++Rule	Para	1996	2001	-	Oct	Sun>=1	0:00	1:00	-
+ # IATA SSIM (1997-09) says Mar 1; go with Shanks & Pottenger.
+ Rule	Para	1997	only	-	Feb	lastSun	0:00	0	-
+ # Shanks & Pottenger say 1999-02-28; IATA SSIM (1999-02) says 1999-02-27, but
+@@ -1569,7 +1568,7 @@
+ # dst method to be from the first Sunday in September to the first Sunday in
+ # April.
+ Rule	Para	2002	2004	-	Apr	Sun>=1	0:00	0	-
+-Rule	Para	2002	2003	-	Sep	Sun>=1	0:00	1:00	S
++Rule	Para	2002	2003	-	Sep	Sun>=1	0:00	1:00	-
+ #
+ # From Jesper Nørgaard Welen (2005-01-02):
+ # There are several sources that claim that Paraguay made
+@@ -1578,7 +1577,7 @@
+ # Decree 1,867 (2004-03-05)
+ # From Carlos Raúl Perasso via Jesper Nørgaard Welen (2006-10-13)
+ # http://www.presidencia.gov.py/decretos/D1867.pdf
+-Rule	Para	2004	2009	-	Oct	Sun>=15	0:00	1:00	S
++Rule	Para	2004	2009	-	Oct	Sun>=15	0:00	1:00	-
+ Rule	Para	2005	2009	-	Mar	Sun>=8	0:00	0	-
+ # From Carlos Raúl Perasso (2010-02-18):
+ # By decree number 3958 issued yesterday
+@@ -1591,7 +1590,7 @@
+ # and that on the first Sunday of the month of October, it is to be set
+ # forward 60 minutes, in all the territory of the Paraguayan Republic.
+ # ...
+-Rule	Para	2010	max	-	Oct	Sun>=1	0:00	1:00	S
++Rule	Para	2010	max	-	Oct	Sun>=1	0:00	1:00	-
+ Rule	Para	2010	2012	-	Apr	Sun>=8	0:00	0	-
+ #
+ # From Steffen Thorsen (2013-03-07):
+@@ -1624,16 +1623,16 @@
+ # Shanks & Pottenger don't have this transition.  Assume 1986 was like 1987.
+ 
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-Rule	Peru	1938	only	-	Jan	 1	0:00	1:00	S
++Rule	Peru	1938	only	-	Jan	 1	0:00	1:00	-
+ Rule	Peru	1938	only	-	Apr	 1	0:00	0	-
+-Rule	Peru	1938	1939	-	Sep	lastSun	0:00	1:00	S
++Rule	Peru	1938	1939	-	Sep	lastSun	0:00	1:00	-
+ Rule	Peru	1939	1940	-	Mar	Sun>=24	0:00	0	-
+-Rule	Peru	1986	1987	-	Jan	 1	0:00	1:00	S
++Rule	Peru	1986	1987	-	Jan	 1	0:00	1:00	-
+ Rule	Peru	1986	1987	-	Apr	 1	0:00	0	-
+-Rule	Peru	1990	only	-	Jan	 1	0:00	1:00	S
++Rule	Peru	1990	only	-	Jan	 1	0:00	1:00	-
+ Rule	Peru	1990	only	-	Apr	 1	0:00	0	-
+ # IATA is ambiguous for 1993/1995; go with Shanks & Pottenger.
+-Rule	Peru	1994	only	-	Jan	 1	0:00	1:00	S
++Rule	Peru	1994	only	-	Jan	 1	0:00	1:00	-
+ Rule	Peru	1994	only	-	Apr	 1	0:00	0	-
+ # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
+ Zone	America/Lima	-5:08:12 -	LMT	1890
+@@ -1679,72 +1678,201 @@
+ # Uruguay
+ # From Paul Eggert (1993-11-18):
+ # Uruguay wins the prize for the strangest peacetime manipulation of the rules.
+-# From Shanks & Pottenger:
++#
++# From Tim Parenti (2018-02-20), per Jeremie Bonjour (2018-01-31) and Michael
++# Deckers (2018-02-20):
++# ... At least they kept good records...
++#
++# http://www.armada.mil.uy/ContenidosPDFs/sohma/web/almanaque/almanaque_2018.pdf#page=36
++# Page 36 of Almanaque 2018, published by the Oceanography, Hydrography, and
++# Meteorology Service of the Uruguayan Navy, seems to give many transitions
++# with greater clarity than we've had before.  It directly references many laws
++# and decrees which are, in turn, referenced below.  They can be viewed in the
++# public archives of the Diario Oficial (in Spanish) at
++# http://www.impo.com.uy/diariooficial/
++#
++# Ley No. 3920 of 1908-06-10 placed the determination of legal time under the
++# auspices of the National Institute for the Prediction of Time.  It is unclear
++# exactly what offset was used during this period, though Ley No. 7200 of
++# 1920-04-23 used the Observatory of the National Meteorological Institute in
++# Montevideo (34° 54' 33" S, 56° 12' 45" W) as its reference meridian,
++# retarding legal time by 15 minutes 9 seconds from 1920-04-30 24:00,
++# resulting in UT-04.  Assume the corresponding LMT of UT-03:44:51 (given on
++# page 725 of the Proceedings of the Second Pan-American Scientific Congress,
++# 1915-1916) was in use, and merely became official from 1908-06-10.
++# https://www.impo.com.uy/diariooficial/1908/06/18/12
++# https://www.impo.com.uy/diariooficial/1920/04/27/9
++#
++# Ley No. 7594 of 1923-06-28 specified legal time as Observatory time advanced
++# by 44 minutes 51 seconds (UT-03) "from 30 September to 31 March", and by 14
++# minutes 51 seconds (UT-03:30) "the rest of the year"; a message from the
++# National Council of Administration the same day, published directly below the
++# law in the Diario Oficial, specified the first transition to be 1923-09-30
++# 24:00.  This effectively established standard time at UT-03:30 with 30
++# minutes DST.  Assume transitions at 24:00 on the specified days until Ley No.
++# 7919 of 1926-03-05 ended this arrangement, repealing all "laws and other
++# provisions which oppose" it, resulting in year-round UT-03:30; a Resolución
++# of 1926-03-11 puts the final transition at 1926-03-31 24:00, the same as it
++# would have been under the previous law.
++# https://www.impo.com.uy/diariooficial/1923/07/02/2
++# https://www.impo.com.uy/diariooficial/1926/03/10/2
++# https://www.impo.com.uy/diariooficial/1926/03/18/2
++#
+ # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
+-# Whitman gives 1923 Oct 1; go with Shanks & Pottenger.
+-Rule	Uruguay	1923	only	-	Oct	 2	 0:00	0:30	HS
++Rule	Uruguay	1923	1925	-	Oct	 1	 0:00	0:30	-
+ Rule	Uruguay	1924	1926	-	Apr	 1	 0:00	0	-
+-Rule	Uruguay	1924	1925	-	Oct	 1	 0:00	0:30	HS
+-Rule	Uruguay	1933	1935	-	Oct	lastSun	 0:00	0:30	HS
+-# Shanks & Pottenger give 1935 Apr 1 0:00 & 1936 Mar 30 0:00; go with Whitman.
+-Rule	Uruguay	1934	1936	-	Mar	Sat>=25	23:30s	0	-
+-Rule	Uruguay	1936	only	-	Nov	 1	 0:00	0:30	HS
+-Rule	Uruguay	1937	1941	-	Mar	lastSun	 0:00	0	-
+-# Whitman gives 1937 Oct 3; go with Shanks & Pottenger.
+-Rule	Uruguay	1937	1940	-	Oct	lastSun	 0:00	0:30	HS
+-# Whitman gives 1941 Oct 24 - 1942 Mar 27, 1942 Dec 14 - 1943 Apr 13,
+-# and 1943 Apr 13 "to present time"; go with Shanks & Pottenger.
+-Rule	Uruguay	1941	only	-	Aug	 1	 0:00	0:30	HS
+-Rule	Uruguay	1942	only	-	Jan	 1	 0:00	0	-
+-Rule	Uruguay	1942	only	-	Dec	14	 0:00	1:00	S
++# From Tim Parenti (2018-02-15):
++# http://www.impo.com.uy/diariooficial/1933/10/27/6
++#
++# It appears Ley No. 9122 of 1933 was never published as such in the Diario
++# Oficial, but instead appeared as Document 26 in the Diario on Friday
++# 1933-10-27 as a decree made Monday 1933-10-23 and filed under the Ministry of
++# National Defense.  It reinstituted a DST of 30 minutes (to UT-03) "from the
++# last Sunday of October...until the last Saturday of March."  In accordance
++# with this provision, the first transition was explicitly specified in Article
++# 2 of the decree as Saturday 1933-10-28 at 24:00; that is, Sunday 1933-10-29
++# at 00:00.  Assume transitions at 00:00 Sunday throughout.
++#
++# Departing from the matter-of-fact nature of previous timekeeping laws, the
++# 1933 decree "consider[s] the advantages of...the advance of legal time":
++#
++#   "Whereas: The measure adopted by almost all nations at the time of the last
++#    World War still persists in North America and Europe, precisely because of
++#    the economic, hygienic, and social advantages derived from such an
++#    emergency measure...
++#
++#    Whereas: The advance of the legal time during the summer seasons, by
++#    displacing social activity near sunrise, favors the citizen populations
++#    and especially the society that creates and works..."
++#
++# It further specified that "necessary measures" be taken to ensure that
++# "public spectacles finish, in general, before [01:00]."
++Rule	Uruguay	1933	1938	-	Oct	lastSun	 0:00	0:30	-
++Rule	Uruguay	1934	1941	-	Mar	lastSat	24:00	0	-
++# From Tim Parenti (2018-02-15):
++# Most of the Rules below, and their contemporaneous Zone lines, have been
++# updated simply to match the Almanaque 2018.  Although the document does not
++# list exact transition times, midnight transitions were already present in our
++# data here for all transitions through 2004-09, and this is both consistent
++# with prior transitions and verified in several decrees marked below between
++# 1939-09 and 2004-09, wherein the relevant text was typically of the form:
++#
++#   "From 0 hours on [date], the legal time of the entire Republic will be...
++#
++#    In accordance with [the preceding], on [previous date] at 24 hours, all
++#    clocks throughout the Republic will be [advanced/retarded] by..."
++#
++# It is possible that there is greater specificity to be found for the Rules
++# below, but it is buried in no fewer than 40 different decrees individually
++# referenced by the Almanaque for the period from 1939-09 to 2014-09.
++# Four-fifths of these were promulgated less than two weeks before taking
++# effect; more than half within a week and none more than 5 weeks.  Only the
++# handful with comments below have been checked with any thoroughness.
++Rule	Uruguay	1939	only	-	Oct	 1	 0:00	0:30	-
++Rule	Uruguay	1940	only	-	Oct	27	 0:00	0:30	-
++# From Tim Parenti (2018-02-15):
++# Decreto 1145 of the Ministry of National Defense, dated 1941-07-26, specified
++# UT-03 from Friday 1941-08-01 00:00, citing an "urgent...need to save fuel".
++# http://www.impo.com.uy/diariooficial/1941/08/04/1
++Rule	Uruguay	1941	only	-	Aug	 1	 0:00	0:30	-
++# From Tim Parenti (2018-02-15):
++# Decreto 1866 of the Ministry of National Defense, dated 1942-12-09, specified
++# further advancement (to UT-02:30) from Sunday 1942-12-13 24:00.  Since clocks
++# never went back to UT-03:30 thereafter, this is modeled as advancing standard
++# time by 30 minutes to UT-03, while retaining 30 minutes of DST.
++# http://www.impo.com.uy/diariooficial/1942/12/16/3
++Rule	Uruguay	1942	only	-	Dec	14	 0:00	0:30	-
+ Rule	Uruguay	1943	only	-	Mar	14	 0:00	0	-
+-Rule	Uruguay	1959	only	-	May	24	 0:00	1:00	S
++Rule	Uruguay	1959	only	-	May	24	 0:00	0:30	-
+ Rule	Uruguay	1959	only	-	Nov	15	 0:00	0	-
+-Rule	Uruguay	1960	only	-	Jan	17	 0:00	1:00	S
++Rule	Uruguay	1960	only	-	Jan	17	 0:00	1:00	-
+ Rule	Uruguay	1960	only	-	Mar	 6	 0:00	0	-
+-Rule	Uruguay	1965	1967	-	Apr	Sun>=1	 0:00	1:00	S
++Rule	Uruguay	1965	only	-	Apr	 4	 0:00	1:00	-
+ Rule	Uruguay	1965	only	-	Sep	26	 0:00	0	-
+-Rule	Uruguay	1966	1967	-	Oct	31	 0:00	0	-
+-Rule	Uruguay	1968	1970	-	May	27	 0:00	0:30	HS
+-Rule	Uruguay	1968	1970	-	Dec	 2	 0:00	0	-
+-Rule	Uruguay	1972	only	-	Apr	24	 0:00	1:00	S
+-Rule	Uruguay	1972	only	-	Aug	15	 0:00	0	-
+-Rule	Uruguay	1974	only	-	Mar	10	 0:00	0:30	HS
+-Rule	Uruguay	1974	only	-	Dec	22	 0:00	1:00	S
+-Rule	Uruguay	1976	only	-	Oct	 1	 0:00	0	-
+-Rule	Uruguay	1977	only	-	Dec	 4	 0:00	1:00	S
+-Rule	Uruguay	1978	only	-	Apr	 1	 0:00	0	-
+-Rule	Uruguay	1979	only	-	Oct	 1	 0:00	1:00	S
+-Rule	Uruguay	1980	only	-	May	 1	 0:00	0	-
+-Rule	Uruguay	1987	only	-	Dec	14	 0:00	1:00	S
+-Rule	Uruguay	1988	only	-	Mar	14	 0:00	0	-
+-Rule	Uruguay	1988	only	-	Dec	11	 0:00	1:00	S
+-Rule	Uruguay	1989	only	-	Mar	12	 0:00	0	-
+-Rule	Uruguay	1989	only	-	Oct	29	 0:00	1:00	S
+-# Shanks & Pottenger say no DST was observed in 1990/1 and 1991/2,
+-# and that 1992/3's DST was from 10-25 to 03-01.  Go with IATA.
+-Rule	Uruguay	1990	1992	-	Mar	Sun>=1	 0:00	0	-
+-Rule	Uruguay	1990	1991	-	Oct	Sun>=21	 0:00	1:00	S
+-Rule	Uruguay	1992	only	-	Oct	18	 0:00	1:00	S
++# From Tim Parenti (2018-02-15):
++# Decreto 321/968 of 1968-05-25, citing emergency drought measures decreed the
++# day before, brought clocks forward 30 minutes from Monday 1968-05-27 00:00.
++# http://www.impo.com.uy/diariooficial/1968/05/30/5
++Rule	Uruguay	1968	only	-	May	27	 0:00	0:30	-
++Rule	Uruguay	1968	only	-	Dec	 1	 0:00	0	-
++# From Tim Parenti (2018-02-15):
++# Decreto 188/970 of 1970-04-23 instituted restrictions on electricity
++# consumption "as a consequence of the current rainfall regime in the country".
++# Articles 13 and 14 advanced clocks by an hour from Saturday 1970-04-25 00:00.
++# http://www.impo.com.uy/diariooficial/1970/04/29/4
++Rule	Uruguay	1970	only	-	Apr	25	 0:00	1:00	-
++Rule	Uruguay	1970	only	-	Jun	14	 0:00	0	-
++Rule	Uruguay	1972	only	-	Apr	23	 0:00	1:00	-
++Rule	Uruguay	1972	only	-	Jul	16	 0:00	0	-
++# From Tim Parenti (2018-02-15):
++# Decreto 29/974 of 1974-01-11, citing "the international rise in the price of
++# oil", advanced clocks by 90 minutes (to UT-01:30).  Decreto 163/974 of
++# 1974-03-04 returned 60 of those minutes (to UT-02:30), and the remaining 30
++# minutes followed in Decreto 679/974 of 1974-08-29.
++# http://www.impo.com.uy/diariooficial/1974/01/22/11
++# http://www.impo.com.uy/diariooficial/1974/03/14/3
++# http://www.impo.com.uy/diariooficial/1974/09/04/6
++Rule	Uruguay	1974	only	-	Jan	13	 0:00	1:30	-
++Rule	Uruguay	1974	only	-	Mar	10	 0:00	0:30	-
++Rule	Uruguay	1974	only	-	Sep	 1	 0:00	0	-
++Rule	Uruguay	1974	only	-	Dec	22	 0:00	1:00	-
++Rule	Uruguay	1975	only	-	Mar	30	 0:00	0	-
++Rule	Uruguay	1976	only	-	Dec	19	 0:00	1:00	-
++Rule	Uruguay	1977	only	-	Mar	 6	 0:00	0	-
++Rule	Uruguay	1977	only	-	Dec	 4	 0:00	1:00	-
++Rule	Uruguay	1978	1979	-	Mar	Sun>=1	 0:00	0	-
++Rule	Uruguay	1978	only	-	Dec	17	 0:00	1:00	-
++Rule	Uruguay	1979	only	-	Apr	29	 0:00	1:00	-
++Rule	Uruguay	1980	only	-	Mar	16	 0:00	0	-
++# From Tim Parenti (2018-02-15):
++# Decreto 725/987 of 1987-12-04 cited "better use of national tourist
++# attractions" to advance clocks one hour from Monday 1987-12-14 00:00.
++# http://www.impo.com.uy/diariooficial/1988/01/25/1
++Rule	Uruguay	1987	only	-	Dec	14	 0:00	1:00	-
++Rule	Uruguay	1988	only	-	Feb	28	 0:00	0	-
++Rule	Uruguay	1988	only	-	Dec	11	 0:00	1:00	-
++Rule	Uruguay	1989	only	-	Mar	 5	 0:00	0	-
++Rule	Uruguay	1989	only	-	Oct	29	 0:00	1:00	-
++Rule	Uruguay	1990	only	-	Feb	25	 0:00	0	-
++# From Tim Parenti (2018-02-15), per Paul Eggert (1999-11-04):
++# IATA agrees as below for 1990-10 through 1993-02.  Per Almanaque 2018, the
++# 1992/1993 season appears to be the first in over half a century where DST
++# both began and ended pursuant to the same decree.
++Rule	Uruguay	1990	1991	-	Oct	Sun>=21	 0:00	1:00	-
++Rule	Uruguay	1991	1992	-	Mar	Sun>=1	 0:00	0	-
++Rule	Uruguay	1992	only	-	Oct	18	 0:00	1:00	-
+ Rule	Uruguay	1993	only	-	Feb	28	 0:00	0	-
+ # From Eduardo Cota (2004-09-20):
+ # The Uruguayan government has decreed a change in the local time....
+-# http://www.presidencia.gub.uy/decretos/2004091502.htm
+-Rule	Uruguay	2004	only	-	Sep	19	 0:00	1:00	S
++# From Tim Parenti (2018-02-15):
++# Decreto 328/004 of 2004-09-15.
++# http://www.impo.com.uy/diariooficial/2004/09/23/documentos.pdf#page=1
++Rule	Uruguay	2004	only	-	Sep	19	 0:00	1:00	-
+ # From Steffen Thorsen (2005-03-11):
+ # Uruguay's DST was scheduled to end on Sunday, 2005-03-13, but in order to
+ # save energy ... it was postponed two weeks....
+-# http://www.presidencia.gub.uy/_Web/noticias/2005/03/2005031005.htm
++# From Tim Parenti (2018-02-15):
++# This 2005 postponement is not in Almanaque 2018.  Go with the contemporaneous
++# reporting, which is confirmed by Decreto 107/005 of 2005-03-10 amending
++# Decreto 328/004:
++# http://www.impo.com.uy/diariooficial/2005/03/15/documentos.pdf#page=1
++# The original decree specified a transition of 2005-03-12 24:00, but the new
++# one specified 2005-03-27 02:00.
+ Rule	Uruguay	2005	only	-	Mar	27	 2:00	0	-
+ # From Eduardo Cota (2005-09-27):
+-# http://www.presidencia.gub.uy/_Web/decretos/2005/09/CM%20119_09%2009%202005_00001.PDF
+-# This means that from 2005-10-09 at 02:00 local time, until 2006-03-12 at
+-# 02:00 local time, official time in Uruguay will be at GMT -2.
+-Rule	Uruguay	2005	only	-	Oct	 9	 2:00	1:00	S
+-Rule	Uruguay	2006	only	-	Mar	12	 2:00	0	-
+-# From Jesper Nørgaard Welen (2006-09-06):
+-# http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202006_00001.PDF
+-#
++# ...from 2005-10-09 at 02:00 local time, until 2006-03-12 at 02:00 local time,
++# official time in Uruguay will be at GMT -2.
++# From Tim Parenti (2018-02-15):
++# Decreto 318/005 of 2005-09-19.
++# http://www.impo.com.uy/diariooficial/2005/09/23/documentos.pdf#page=1
++Rule	Uruguay	2005	only	-	Oct	 9	 2:00	1:00	-
++Rule	Uruguay	2006	2015	-	Mar	Sun>=8	 2:00	0	-
++# From Tim Parenti (2018-02-15), per Jesper Nørgaard Welen (2006-09-06):
++# Decreto 311/006 of 2006-09-04 established regular DST from the first Sunday
++# of October at 02:00 through the second Sunday of March at 02:00.  Almanaque
++# 2018 appears to have a few typoed dates through this period; ignore them.
++# http://www.impo.com.uy/diariooficial/2006/09/08/documentos.pdf#page=1
++Rule	Uruguay	2006	2014	-	Oct	Sun>=1	 2:00	1:00	-
+ # From Steffen Thorsen (2015-06-30):
+ # ... it looks like they will not be using DST the coming summer:
+ # http://www.elobservador.com.uy/gobierno-resolvio-que-no-habra-cambio-horario-verano-n656787
+@@ -1754,17 +1882,19 @@
+ # instead of out to dinner.
+ # From Pablo Camargo (2015-07-13):
+ # http://archivo.presidencia.gub.uy/sci/decretos/2015/06/cons_min_201.pdf
+-# [dated 2015-06-29; repeals Decree 311/006 dated 2006-09-04]
+-Rule	Uruguay	2006	2014	-	Oct	Sun>=1	 2:00	1:00	S
+-Rule	Uruguay	2007	2015	-	Mar	Sun>=8	 2:00	0	-
++# From Tim Parenti (2018-02-15):
++# Decreto 178/015 of 2015-06-29; repeals Decreto 311/006.
+ 
+ # This Zone can be simplified once we assume zic %z.
+-Zone America/Montevideo	-3:44:44 -	LMT	1898 Jun 28
+-			-3:44:44 -	MMT	1920 May  1 # Montevideo MT
++Zone America/Montevideo	-3:44:51 -	LMT	1908 Jun 10
++			-3:44:51 -	MMT	1920 May  1 # Montevideo MT
++			-4:00	-	-04	1923 Oct  1
+ 			-3:30	Uruguay	-0330/-03 1942 Dec 14
++			-3:00	Uruguay	-03/-0230 1960
+ 			-3:00	Uruguay	-03/-02	1968
+-			-3:00	Uruguay	-03/-0230 1971
++			-3:00	Uruguay	-03/-0230 1970
+ 			-3:00	Uruguay	-03/-02	1974
++			-3:00	Uruguay	-03/-0130 1974 Mar 10
+ 			-3:00	Uruguay	-03/-0230 1974 Dec 22
+ 			-3:00	Uruguay	-03/-02
+ 
+--- contrib/tzdata/theory.html.orig
++++ contrib/tzdata/theory.html
+@@ -1,4 +1,3 @@
+-<!DOCTYPE html>
+ <html lang="en">
+ <head>
+   <title>Theory and pragmatics of the tz code and data</title>
+@@ -5,22 +4,17 @@
+   <meta charset="UTF-8">
+ </head>
+ 
+-<!-- The somewhat-unusal indenting style in this file is intended to
+-     shrink the output of the shell command 'diff Theory Theory.html',
+-     where 'Theory' was the plain text file that this file is derived
+-     from.  The 'Theory' file used leading white space to indent, and
+-     when possible that indentation is preserved here.  Eventually we
+-     may stop doing this and remove this comment.  -->
+-
+ <body>
+-  <h1>Theory and pragmatics of the tz code and data</h1>
++<h1>Theory and pragmatics of the <code><abbr>tz</abbr></code> code and data</h1>
+   <h3>Outline</h3>
+   <nav>
+     <ul>
+-      <li><a href="#scope">Scope of the tz database</a></li>
+-      <li><a href="#naming">Names of time zone rules</a></li>
++      <li><a href="#scope">Scope of the <code><abbr>tz</abbr></code>
++	  database</a></li>
++      <li><a href="#naming">Names of time zone rulesets</a></li>
+       <li><a href="#abbreviations">Time zone abbreviations</a></li>
+-      <li><a href="#accuracy">Accuracy of the tz database</a></li>
++      <li><a href="#accuracy">Accuracy of the <code><abbr>tz</abbr></code>
++	  database</a></li>
+       <li><a href="#functions">Time and date functions</a></li>
+       <li><a href="#stability">Interface stability</a></li>
+       <li><a href="#calendar">Calendrical issues</a></li>
+@@ -28,20 +22,27 @@
+     </ul>
+   </nav>
+ 
+-
+-  <section>
+-    <h2 id="scope">Scope of the tz database</h2>
++<section>
++  <h2 id="scope">Scope of the <code><abbr>tz</abbr></code> database</h2>
+ <p>
+-The tz database attempts to record the history and predicted future of
+-all computer-based clocks that track civil time.  To represent this
+-data, the world is partitioned into regions whose clocks all agree
+-about timestamps that occur after the somewhat-arbitrary cutoff point
+-of the POSIX Epoch (1970-01-01 00:00:00 UTC).  For each such region,
+-the database records all known clock transitions, and labels the region
+-with a notable location.  Although 1970 is a somewhat-arbitrary
+-cutoff, there are significant challenges to moving the cutoff earlier
+-even by a decade or two, due to the wide variety of local practices
+-before computer timekeeping became prevalent.
++The <a
++href="https://www.iana.org/time-zones"><code><abbr>tz</abbr></code>
++database</a> attempts to record the history and predicted future of
++all computer-based clocks that track civil time.
++It organizes <a href="tz-link.html">time zone and daylight saving time
++data</a> by partitioning the world into <a
++href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones">regions</a>
++whose clocks all agree about timestamps that occur after the of the <a
++href="https://en.wikipedia.org/wiki/Unix_time">POSIX Epoch</a>
++(1970-01-01 00:00:00 <a
++href="https://en.wikipedia.org/wiki/Coordinated_Universal_Time"><abbr
++title="Coordinated Universal Time">UTC</abbr></a>).
++The database labels each such region with a notable location and
++records all known clock transitions for that location.
++Although 1970 is a somewhat-arbitrary cutoff, there are significant
++challenges to moving the cutoff earlier even by a decade or two, due
++to the wide variety of local practices before computer timekeeping
++became prevalent.
+ </p>
+ 
+ <p>
+@@ -59,193 +60,218 @@
+ </p>
+ 
+ <p>
+-As described below, reference source code for using the tz database is
+-also available.  The tz code is upwards compatible with POSIX, an
+-international standard for UNIX-like systems.  As of this writing, the
+-current edition of POSIX is:
+-  <a href="http://pubs.opengroup.org/onlinepubs/9699919799/">
+-  The Open Group Base Specifications Issue 7</a>,
+-  IEEE Std 1003.1-2008, 2016 Edition.
++As described below, reference source code for using the
++<code><abbr>tz</abbr></code> database is also available.
++The <code><abbr>tz</abbr></code> code is upwards compatible with <a
++href="https://en.wikipedia.org/wiki/POSIX">POSIX</a>, an international
++standard for <a
++href="https://en.wikipedia.org/wiki/Unix">UNIX</a>-like systems.
++As of this writing, the current edition of POSIX is: <a
++href="http://pubs.opengroup.org/onlinepubs/9699919799/"> The Open
++Group Base Specifications Issue 7</a>, IEEE Std 1003.1-2008, 2016
++Edition.
++Because the database's scope encompasses real-world changes to civil
++timekeeping, its model for describing time is more complex than the
++standard and daylight saving times supported by POSIX.
++A <code><abbr>tz</abbr></code> region corresponds to a ruleset that can
++have more than two changes per year, these changes need not merely
++flip back and forth between two alternatives, and the rules themselves
++can change at times.
++Whether and when a <code><abbr>tz</abbr></code> region changes its
++clock, and even the region's notional base offset from UTC, are variable.
++It doesn't even really make sense to talk about a region's
++"base offset", since it is not necessarily a single number.
+ </p>
+-  </section>
+ 
++</section>
+ 
+-
+-  <section>
+-    <h2 id="naming">Names of time zone rules</h2>
++<section>
++  <h2 id="naming">Names of time zone rulesets</h2>
+ <p>
+-Each of the database's time zone rules has a unique name.
++Each <code><abbr>tz</abbr></code> region has a unique name that
++corresponds to a set of time zone rules.
+ Inexperienced users are not expected to select these names unaided.
+ Distributors should provide documentation and/or a simple selection
+ interface that explains the names; for one example, see the 'tzselect'
+-program in the tz code.  The
+-<a href="http://cldr.unicode.org/">Unicode Common Locale Data
+-Repository</a> contains data that may be useful for other
+-selection interfaces.
++program in the <code><abbr>tz</abbr></code> code.
++The <a href="http://cldr.unicode.org/">Unicode Common Locale Data
++Repository</a> contains data that may be useful for other selection
++interfaces.
+ </p>
+ 
+ <p>
+-The time zone rule naming conventions attempt to strike a balance
++The naming conventions attempt to strike a balance
+ among the following goals:
+ </p>
++
+ <ul>
+   <li>
+-   Uniquely identify every region where clocks have agreed since 1970.
+-   This is essential for the intended use: static clocks keeping local
+-   civil time.
++    Uniquely identify every region where clocks have agreed since 1970.
++    This is essential for the intended use: static clocks keeping local
++    civil time.
+   </li>
+   <li>
+-   Indicate to experts where that region is.
++    Indicate to experts where that region is.
+   </li>
+   <li>
+-   Be robust in the presence of political changes.  For example, names
+-   of countries are ordinarily not used, to avoid incompatibilities
+-   when countries change their name (e.g. Zaire&rarr;Congo) or when
+-   locations change countries (e.g. Hong Kong from UK colony to
+-   China).
++    Be robust in the presence of political changes.
++    For example, names of countries are ordinarily not used, to avoid
++    incompatibilities when countries change their name (e.g.,
++    Zaire&rarr;Congo) or when locations change countries (e.g., Hong
++    Kong from UK colony to China).
+   </li>
+   <li>
+-   Be portable to a wide variety of implementations.
++    Be portable to a wide variety of implementations.
+   </li>
+   <li>
+-   Use a consistent naming conventions over the entire world.
++    Use a consistent naming conventions over the entire world.
+   </li>
+ </ul>
++
+ <p>
+-Names normally have the
+-form <var>AREA</var><code>/</code><var>LOCATION</var>,
+-where <var>AREA</var> is the name of a continent or ocean,
+-and <var>LOCATION</var> is the name of a specific
+-location within that region.  North and South America share the same
+-area, '<code>America</code>'.  Typical names are
+-'<code>Africa/Cairo</code>', '<code>America/New_York</code>', and
+-'<code>Pacific/Honolulu</code>'.
++Names normally have the form
++<var>AREA</var><code>/</code><var>LOCATION</var>, where
++<var>AREA</var> is the name of a continent or ocean, and
++<var>LOCATION</var> is the name of a specific location within that
++region.
++North and South America share the same area, '<code>America</code>'.
++Typical names are '<code>Africa/Cairo</code>',
++'<code>America/New_York</code>', and '<code>Pacific/Honolulu</code>'.
+ </p>
+ 
+ <p>
+-Here are the general rules used for choosing location names,
++Here are the general guidelines used for
++choosing <code><abbr>tz</abbr></code> region names,
+ in decreasing order of importance:
+ </p>
++
+ <ul>
+   <li>
+-	Use only valid POSIX file name components (i.e., the parts of
+-		names other than '<code>/</code>').  Do not use the file name
+-		components '<code>.</code>' and '<code>..</code>'.
+-		Within a file name component,
+-		use only ASCII letters, '<code>.</code>',
+-		'<code>-</code>' and '<code>_</code>'.  Do not use
+-		digits, as that might create an ambiguity with POSIX
+-		TZ strings.  A file name component must not exceed 14
+-		characters or start with '<code>-</code>'.  E.g.,
+-		prefer '<code>Brunei</code>' to
+-		'<code>Bandar_Seri_Begawan</code>'.  Exceptions: see
+-		the discussion
+-		of legacy names below.
++    Use only valid POSIX file name components (i.e., the parts of
++    names other than '<code>/</code>').
++    Do not use the file name components '<code>.</code>' and
++    '<code>..</code>'.
++    Within a file name component, use only <a
++    href="https://en.wikipedia.org/wiki/ASCII">ASCII</a> letters,
++    '<code>.</code>', '<code>-</code>' and '<code>_</code>'.
++    Do not use digits, as that might create an ambiguity with <a
++    href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">POSIX
++    <code>TZ</code> strings</a>.
++    A file name component must not exceed 14 characters or start with
++    '<code>-</code>'.
++    E.g., prefer '<code>Brunei</code>' to '<code>Bandar_Seri_Begawan</code>'.
++    Exceptions: see the discussion of legacy names below.
+   </li>
+   <li>
+-	A name must not be empty, or contain '<code>//</code>', or
+-	start or end with '<code>/</code>'.
++    A name must not be empty, or contain '<code>//</code>', or
++    start or end with '<code>/</code>'.
+   </li>
+   <li>
+-	Do not use names that differ only in case.  Although the reference
+-		implementation is case-sensitive, some other implementations
+-		are not, and they would mishandle names differing only in case.
++    Do not use names that differ only in case.
++    Although the reference implementation is case-sensitive, some
++    other implementations are not, and they would mishandle names
++    differing only in case.
+   </li>
+   <li>
+-	If one name <var>A</var> is an initial prefix of another
+-		name <var>AB</var> (ignoring case), then <var>B</var>
+-		must not start with '<code>/</code>', as a
+-		regular file cannot have
+-		the same name as a directory in POSIX.  For example,
+-		'<code>America/New_York</code>' precludes
+-		'<code>America/New_York/Bronx</code>'.
++    If one name <var>A</var> is an initial prefix of another
++    name <var>AB</var> (ignoring case), then <var>B</var> must not
++    start with '<code>/</code>', as a regular file cannot have the
++    same name as a directory in POSIX.
++    For example, '<code>America/New_York</code>' precludes
++    '<code>America/New_York/Bronx</code>'.
+   </li>
+   <li>
+-	Uninhabited regions like the North Pole and Bouvet Island
+-		do not need locations, since local time is not defined there.
++    Uninhabited regions like the North Pole and Bouvet Island
++    do not need locations, since local time is not defined there.
+   </li>
+   <li>
+-	There should typically be at least one name for each ISO 3166-1
+-		officially assigned two-letter code for an inhabited country
+-		or territory.
++    There should typically be at least one name for each <a
++    href="https://en.wikipedia.org/wiki/ISO_3166-1"><abbr
++    title="International Organization for Standardization">ISO</abbr>
++    3166-1</a> officially assigned two-letter code for an inhabited
++    country or territory.
+   </li>
+   <li>
+-	If all the clocks in a region have agreed since 1970,
+-		don't bother to include more than one location
+-		even if subregions' clocks disagreed before 1970.
+-		Otherwise these tables would become annoyingly large.
++    If all the clocks in a region have agreed since 1970,
++    don't bother to include more than one location
++    even if subregions' clocks disagreed before 1970.
++    Otherwise these tables would become annoyingly large.
+   </li>
+   <li>
+-	If a name is ambiguous, use a less ambiguous alternative;
+-		e.g. many cities are named San José and Georgetown, so
+-		prefer '<code>Costa_Rica</code>' to '<code>San_Jose</code>' and '<code>Guyana</code>' to '<code>Georgetown</code>'.
++    If a name is ambiguous, use a less ambiguous alternative;
++    e.g., many cities are named San José and Georgetown, so
++    prefer '<code>Costa_Rica</code>' to '<code>San_Jose</code>' and
++    '<code>Guyana</code>' to '<code>Georgetown</code>'.
+   </li>
+   <li>
+-	Keep locations compact.  Use cities or small islands, not countries
+-		or regions, so that any future time zone changes do not split
+-		locations into different time zones.  E.g. prefer
+-		'<code>Paris</code>' to '<code>France</code>', since
+-		France has had multiple time zones.
++    Keep locations compact.
++    Use cities or small islands, not countries or regions, so that any
++    future changes do not split individual locations into different
++    <code><abbr>tz</abbr></code> regions.
++    E.g., prefer '<code>Paris</code>' to '<code>France</code>', since
++    <a href="https://en.wikipedia.org/wiki/Time_in_France#History">France
++    has had multiple time zones</a>.
+   </li>
+   <li>
+-	Use mainstream English spelling, e.g. prefer
+-		'<code>Rome</code>' to '<code>Roma</code>', and prefer
+-		'<code>Athens</code>' to the Greek
+-		'<code>Αθήνα</code>' or the Romanized
+-		'<code>Athína</code>'.
+-		The POSIX file name restrictions encourage this rule.
++    Use mainstream English spelling, e.g., prefer '<code>Rome</code>'
++    to '<code>Roma</code>', and prefer '<code>Athens</code>' to the
++    Greek '<code>Αθήνα</code>' or the Romanized '<code>Athína</code>'.
++    The POSIX file name restrictions encourage this guideline.
+   </li>
+   <li>
+-	Use the most populous among locations in a zone,
+-		e.g. prefer '<code>Shanghai</code>' to
+-		'<code>Beijing</code>'.  Among locations with
+-		similar populations, pick the best-known location,
+-		e.g. prefer '<code>Rome</code>' to '<code>Milan</code>'.
++    Use the most populous among locations in a region,
++    e.g., prefer '<code>Shanghai</code>' to
++    '<code>Beijing</code>'.
++    Among locations with similar populations, pick the best-known
++    location, e.g., prefer '<code>Rome</code>' to
++    '<code>Milan</code>'.
+   </li>
+   <li>
+-	Use the singular form, e.g. prefer '<code>Canary</code>' to '<code>Canaries</code>'.
++    Use the singular form, e.g., prefer '<code>Canary</code>' to
++    '<code>Canaries</code>'.
+   </li>
+   <li>
+-	Omit common suffixes like '<code>_Islands</code>' and
+-		'<code>_City</code>', unless that would lead to
+-		ambiguity.  E.g. prefer '<code>Cayman</code>' to
+-		'<code>Cayman_Islands</code>' and
+-		'<code>Guatemala</code>' to
+-		'<code>Guatemala_City</code>', but prefer
+-		'<code>Mexico_City</code>' to '<code>Mexico</code>'
+-		because the country
+-		of Mexico has several time zones.
++    Omit common suffixes like '<code>_Islands</code>' and
++    '<code>_City</code>', unless that would lead to ambiguity.
++    E.g., prefer '<code>Cayman</code>' to
++    '<code>Cayman_Islands</code>' and '<code>Guatemala</code>' to
++    '<code>Guatemala_City</code>', but prefer
++    '<code>Mexico_City</code>' to '<code>Mexico</code>'
++    because <a href="https://en.wikipedia.org/wiki/Time_in_Mexico">the
++    country of Mexico has several time zones</a>.
+   </li>
+   <li>
+-	Use '<code>_</code>' to represent a space.
++    Use '<code>_</code>' to represent a space.
+   </li>
+   <li>
+-	Omit '<code>.</code>' from abbreviations in names, e.g. prefer
+-		'<code>St_Helena</code>' to '<code>St._Helena</code>'.
++    Omit '<code>.</code>' from abbreviations in names.
++    E.g., prefer '<code>St_Helena</code>' to '<code>St._Helena</code>'.
+   </li>
+   <li>
+-	Do not change established names if they only marginally
+-		violate the above rules.  For example, don't change
+-		the existing name '<code>Rome</code>' to
+-		'<code>Milan</code>' merely because
+-		Milan's population has grown to be somewhat greater
+-		than Rome's.
++    Do not change established names if they only marginally violate
++    the above guidelines.
++    For example, don't change the existing name '<code>Rome</code>' to
++    '<code>Milan</code>' merely because Milan's population has grown
++    to be somewhat greater than Rome's.
+   </li>
+   <li>
+-	If a name is changed, put its old spelling in the
+-		'<code>backward</code>' file.
+-		This means old spellings will continue to work.
++    If a name is changed, put its old spelling in the
++    '<code>backward</code>' file.
++    This means old spellings will continue to work.
+   </li>
+ </ul>
+ 
+ <p>
+ The file '<code>zone1970.tab</code>' lists geographical locations used
+-to name time
+-zone rules.  It is intended to be an exhaustive list of names for
+-geographic regions as described above; this is a subset of the names
+-in the data.  Although a '<code>zone1970.tab</code>' location's longitude
+-corresponds to its LMT offset with one hour for every 15&deg; east
+-longitude, this relationship is not exact.
++to name <code><abbr>tz</abbr></code> regions.
++It is intended to be an exhaustive list of names for geographic
++regions as described above; this is a subset of the names in the data.
++Although a '<code>zone1970.tab</code>' location's
++<a href="https://en.wikipedia.org/wiki/Longitude">longitude</a>
++corresponds to
++its <a href="https://en.wikipedia.org/wiki/Local_mean_time">local mean
++time (<abbr>LMT</abbr>)</a> offset with one hour for every 15&deg;
++east longitude, this relationship is not exact.
+ </p>
+ 
+ <p>
+@@ -254,202 +280,233 @@
+ See the file '<code>backward</code>' for most of these older names
+ (e.g., '<code>US/Eastern</code>' instead of '<code>America/New_York</code>').
+ The other old-fashioned names still supported are
+-'<code>WET</code>', '<code>CET</code>', '<code>MET</code>', and '<code>EET</code>' (see the file '<code>europe</code>').
++'<code>WET</code>', '<code>CET</code>', '<code>MET</code>', and
++'<code>EET</code>' (see the file '<code>europe</code>').
+ </p>
+ 
+ <p>
+ Older versions of this package defined legacy names that are
+-incompatible with the first rule of location names, but which are
+-still supported.  These legacy names are mostly defined in the file
+-'<code>etcetera</code>'.  Also, the file '<code>backward</code>' defines the legacy names
+-'<code>GMT0</code>', '<code>GMT-0</code>' and '<code>GMT+0</code>', and the file '<code>northamerica</code>' defines the
+-legacy names '<code>EST5EDT</code>', '<code>CST6CDT</code>', '<code>MST7MDT</code>', and '<code>PST8PDT</code>'.
++incompatible with the first guideline of location names, but which are
++still supported.
++These legacy names are mostly defined in the file
++'<code>etcetera</code>'.
++Also, the file '<code>backward</code>' defines the legacy names
++'<code>GMT0</code>', '<code>GMT-0</code>' and '<code>GMT+0</code>',
++and the file '<code>northamerica</code>' defines the legacy names
++'<code>EST5EDT</code>', '<code>CST6CDT</code>',
++'<code>MST7MDT</code>', and '<code>PST8PDT</code>'.
+ </p>
+ 
+ <p>
+-Excluding '<code>backward</code>' should not affect the other data.  If
+-'<code>backward</code>' is excluded, excluding '<code>etcetera</code>' should not affect the
+-remaining data.
++Excluding '<code>backward</code>' should not affect the other data.
++If '<code>backward</code>' is excluded, excluding
++'<code>etcetera</code>' should not affect the remaining data.
+ </p>
++</section>
+ 
+-
+-  </section>
+-  <section>
+-    <h2 id="abbreviations">Time zone abbreviations</h2>
++<section>
++  <h2 id="abbreviations">Time zone abbreviations</h2>
+ <p>
+ When this package is installed, it generates time zone abbreviations
+ like '<code>EST</code>' to be compatible with human tradition and POSIX.
+-Here are the general rules used for choosing time zone abbreviations,
++Here are the general guidelines used for choosing time zone abbreviations,
+ in decreasing order of importance:
++</p>
++
+ <ul>
+   <li>
+-	Use three to six characters that are ASCII alphanumerics or
+-		'<code>+</code>' or '<code>-</code>'.
+-		Previous editions of this database also used characters like
+-		'<code> </code>' and '<code>?</code>', but these
+-		characters have a special meaning to
+-		the shell and cause commands like
+-			'<code>set `date`</code>'
+-		to have unexpected effects.
+-		Previous editions of this rule required upper-case letters,
+-		but the Congressman who introduced Chamorro Standard Time
+-		preferred "ChST", so lower-case letters are now allowed.
+-		Also, POSIX from 2001 on relaxed the rule to allow
+-		'<code>-</code>', '<code>+</code>',
+-		and alphanumeric characters from the portable character set
+-		in the current locale.  In practice ASCII alphanumerics and
+-		'<code>+</code>' and '<code>-</code>' are safe in all locales.
++    Use three to six characters that are ASCII alphanumerics or
++    '<code>+</code>' or '<code>-</code>'.
++    Previous editions of this database also used characters like
++    '<code> </code>' and '<code>?</code>', but these characters have a
++    special meaning to the shell and cause commands like
++    '<code><a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set">set</a>
++    `<a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html">date</a>`</code>'
++    to have unexpected effects.
++    Previous editions of this guideline required upper-case letters, but the
++    Congressman who introduced
++    <a href="https://en.wikipedia.org/wiki/Chamorro_Time_Zone">Chamorro
++    Standard Time</a> preferred "ChST", so lower-case letters are now
++    allowed.
++    Also, POSIX from 2001 on relaxed the rule to allow '<code>-</code>',
++    '<code>+</code>', and alphanumeric characters from the portable
++    character set in the current locale.
++    In practice ASCII alphanumerics and '<code>+</code>' and
++    '<code>-</code>' are safe in all locales.
+ 
+-		In other words, in the C locale the POSIX extended regular
+-		expression <code>[-+[:alnum:]]{3,6}</code> should match
+-		the abbreviation.
+-		This guarantees that all abbreviations could have been
+-		specified by a POSIX TZ string.
++    <p>
++    In other words, in the C locale the POSIX extended regular
++    expression <code>[-+[:alnum:]]{3,6}</code> should match the
++    abbreviation.
++    This guarantees that all abbreviations could have been specified by a
++    POSIX <code>TZ</code> string.
++    </p>
+   </li>
+   <li>
+-	Use abbreviations that are in common use among English-speakers,
+-		e.g. 'EST' for Eastern Standard Time in North America.
+-		We assume that applications translate them to other languages
+-		as part of the normal localization process; for example,
+-		a French application might translate 'EST' to 'HNE'.
++    Use abbreviations that are in common use among English-speakers,
++    e.g., 'EST' for Eastern Standard Time in North America.
++    We assume that applications translate them to other languages
++    as part of the normal localization process; for example,
++    a French application might translate 'EST' to 'HNE'.
+ 
+-<p><small>These abbreviations (for standard/daylight/etc. time) are:
+-ACST/ACDT Australian Central,
+-AST/ADT/APT/AWT/ADDT Atlantic,
+-AEST/AEDT Australian Eastern,
+-AHST/AHDT Alaska-Hawaii,
+-AKST/AKDT Alaska,
+-AWST/AWDT Australian Western,
+-BST/BDT Bering,
+-CAT/CAST Central Africa,
+-CET/CEST/CEMT Central European,
+-ChST Chamorro,
+-CST/CDT/CWT/CPT/CDDT Central [North America],
+-CST/CDT China,
+-GMT/BST/IST/BDST Greenwich,
+-EAT East Africa,
+-EST/EDT/EWT/EPT/EDDT Eastern [North America],
+-EET/EEST Eastern European,
+-GST Guam,
+-HST/HDT Hawaii,
+-HKT/HKST Hong Kong,
+-IST India,
+-IST/GMT Irish,
+-IST/IDT/IDDT Israel,
+-JST/JDT Japan,
+-KST/KDT Korea,
+-MET/MEST Middle European (a backward-compatibility alias for Central European),
+-MSK/MSD Moscow,
+-MST/MDT/MWT/MPT/MDDT Mountain,
+-NST/NDT/NWT/NPT/NDDT Newfoundland,
+-NST/NDT/NWT/NPT Nome,
+-NZMT/NZST New Zealand through 1945,
+-NZST/NZDT New Zealand 1946&ndash;present,
+-PKT/PKST Pakistan,
+-PST/PDT/PWT/PPT/PDDT Pacific,
+-SAST South Africa,
+-SST Samoa,
+-WAT/WAST West Africa,
+-WET/WEST/WEMT Western European,
+-WIB Waktu Indonesia Barat,
+-WIT Waktu Indonesia Timur,
+-WITA Waktu Indonesia Tengah,
+-YST/YDT/YWT/YPT/YDDT Yukon</small>.</p>
++    <p>
++    <small>These abbreviations (for standard/daylight/etc. time) are:
++      ACST/ACDT Australian Central,
++      AST/ADT/APT/AWT/ADDT Atlantic,
++      AEST/AEDT Australian Eastern,
++      AHST/AHDT Alaska-Hawaii,
++      AKST/AKDT Alaska,
++      AWST/AWDT Australian Western,
++      BST/BDT Bering,
++      CAT/CAST Central Africa,
++      CET/CEST/CEMT Central European,
++      ChST Chamorro,
++      CST/CDT/CWT/CPT/CDDT Central [North America],
++      CST/CDT China,
++      GMT/BST/IST/BDST Greenwich,
++      EAT East Africa,
++      EST/EDT/EWT/EPT/EDDT Eastern [North America],
++      EET/EEST Eastern European,
++      GST Guam,
++      HST/HDT Hawaii,
++      HKT/HKST Hong Kong,
++      IST India,
++      IST/GMT Irish,
++      IST/IDT/IDDT Israel,
++      JST/JDT Japan,
++      KST/KDT Korea,
++      MET/MEST Middle European (a backward-compatibility alias for
++	Central European),
++      MSK/MSD Moscow,
++      MST/MDT/MWT/MPT/MDDT Mountain,
++      NST/NDT/NWT/NPT/NDDT Newfoundland,
++      NST/NDT/NWT/NPT Nome,
++      NZMT/NZST New Zealand through 1945,
++      NZST/NZDT New Zealand 1946&ndash;present,
++      PKT/PKST Pakistan,
++      PST/PDT/PWT/PPT/PDDT Pacific,
++      SAST South Africa,
++      SST Samoa,
++      WAT/WAST West Africa,
++      WET/WEST/WEMT Western European,
++      WIB Waktu Indonesia Barat,
++      WIT Waktu Indonesia Timur,
++      WITA Waktu Indonesia Tengah,
++      YST/YDT/YWT/YPT/YDDT Yukon</small>.
++    </p>
+   </li>
+   <li>
+-	For zones whose times are taken from a city's longitude, use the
+-traditional <var>x</var>MT notation. The only abbreviation like this
+-in current use is 'GMT'. The others are for timestamps before 1960,
+-except that Monrovia Mean Time persisted until 1972. Typically,
+-numeric abbreviations (e.g., '<code>-</code>004430' for MMT) would
+-cause trouble here, as the numeric strings would exceed the POSIX length limit.
++    <p>
++    For times taken from a city's longitude, use the
++    traditional <var>x</var>MT notation.
++    The only abbreviation like this in current use is '<abbr>GMT</abbr>'.
++    The others are for timestamps before 1960,
++    except that Monrovia Mean Time persisted until 1972.
++    Typically, numeric abbreviations (e.g., '<code>-</code>004430' for
++    MMT) would cause trouble here, as the numeric strings would exceed
++    the POSIX length limit.
++    </p>
+ 
+-<p><small>These abbreviations are:
+-AMT Amsterdam, Asunción, Athens;
+-BMT Baghdad, Bangkok, Batavia, Bern, Bogotá, Bridgetown, Brussels, Bucharest;
+-CMT Calamarca, Caracas, Chisinau, Colón, Copenhagen, Córdoba;
+-DMT Dublin/Dunsink;
+-EMT Easter;
+-FFMT Fort-de-France;
+-FMT Funchal;
+-GMT Greenwich;
+-HMT Havana, Helsinki, Horta, Howrah;
+-IMT Irkutsk, Istanbul;
+-JMT Jerusalem;
+-KMT Kaunas, Kiev, Kingston;
+-LMT Lima, Lisbon, local, Luanda;
+-MMT Macassar, Madras, Malé, Managua, Minsk, Monrovia, Montevideo, Moratuwa,
+- Moscow;
+-PLMT Phù Liễn;
+-PMT Paramaribo, Paris, Perm, Pontianak, Prague;
+-PMMT Port Moresby;
+-QMT Quito;
+-RMT Rangoon, Riga, Rome;
+-SDMT Santo Domingo;
+-SJMT San José;
+-SMT Santiago, Simferopol, Singapore, Stanley;
+-TBMT Tbilisi;
+-TMT Tallinn, Tehran;
+-WMT Warsaw</small>.</p>
++    <p>
++    <small>These abbreviations are:
++      AMT Amsterdam, Asunción, Athens;
++      BMT Baghdad, Bangkok, Batavia, Bern, Bogotá, Bridgetown, Brussels,
++	Bucharest;
++      CMT Calamarca, Caracas, Chisinau, Colón, Copenhagen, Córdoba;
++      DMT Dublin/Dunsink;
++      EMT Easter;
++      FFMT Fort-de-France;
++      FMT Funchal;
++      GMT Greenwich;
++      HMT Havana, Helsinki, Horta, Howrah;
++      IMT Irkutsk, Istanbul;
++      JMT Jerusalem;
++      KMT Kaunas, Kiev, Kingston;
++      LMT Lima, Lisbon, local, Luanda;
++      MMT Macassar, Madras, Malé, Managua, Minsk, Monrovia, Montevideo,
++	Moratuwa, Moscow;
++      PLMT Phù Liễn;
++      PMT Paramaribo, Paris, Perm, Pontianak, Prague;
++      PMMT Port Moresby;
++      QMT Quito;
++      RMT Rangoon, Riga, Rome;
++      SDMT Santo Domingo;
++      SJMT San José;
++      SMT Santiago, Simferopol, Singapore, Stanley;
++      TBMT Tbilisi;
++      TMT Tallinn, Tehran;
++      WMT Warsaw</small>.
++    </p>
+ 
+-<p><small>A few abbreviations also follow the pattern that
+-GMT/BST established for time in the UK. They are:
+-
+-CMT/BST for Calamarca Mean Time and Bolivian Summer Time
+-1890&ndash;1932, DMT/IST for Dublin/Dunsink Mean Time and Irish Summer Time
+-1880&ndash;1916, MMT/MST/MDST for Moscow 1880&ndash;1919, and RMT/LST
+-for Riga Mean Time and Latvian Summer time 1880&ndash;1926.
+-An extra-special case is SET for Swedish Time (<em>svensk
+-normaltid</em>) 1879&ndash;1899, 3&deg; west of the Stockholm
+-Observatory.</small></p>
++    <p>
++    <small>A few abbreviations also follow the pattern that
++    <abbr>GMT<abbr>/<abbr>BST</abbr> established for time in the UK.
++    They are:
++      CMT/BST for Calamarca Mean Time and Bolivian Summer Time
++	1890&ndash;1932,
++      DMT/IST for Dublin/Dunsink Mean Time and Irish Summer Time
++	1880&ndash;1916,
++      MMT/MST/MDST for Moscow 1880&ndash;1919, and
++      RMT/LST for Riga Mean Time and Latvian Summer time 1880&ndash;1926.
++    An extra-special case is SET for Swedish Time (<em>svensk
++    normaltid</em>) 1879&ndash;1899, 3&deg; west of the Stockholm
++    Observatory.</small>
++    </p>
+   </li>
+   <li>
+-	Use 'LMT' for local mean time of locations before the introduction
+-		of standard time; see "<a href="#scope">Scope of the
+-		tz database</a>".
++    Use '<abbr>LMT</abbr>' for local mean time of locations before the
++    introduction of standard time; see "<a href="#scope">Scope of the
++    <code><abbr>tz</abbr></code> database</a>".
+   </li>
+   <li>
+-	If there is no common English abbreviation, use numeric offsets like
+-		<code>-</code>05 and <code>+</code>0830 that are
+-		generated by zic's <code>%z</code> notation.
++    If there is no common English abbreviation, use numeric offsets like
++    <code>-</code>05 and <code>+</code>0830 that are generated
++    by <code>zic</code>'s <code>%z</code> notation.
+   </li>
+   <li>
+-	Use current abbreviations for older timestamps to avoid confusion.
+-		For example, in 1910 a common English abbreviation for UT +01
+-		in central Europe was 'MEZ' (short for both "Middle European
+-		Zone" and for "Mitteleuropäische Zeit" in German).  Nowadays
+-		'CET' ("Central European Time") is more common in English, and
+-		the database uses 'CET' even for circa-1910 timestamps as this
+-		is less confusing for modern users and avoids the need for
+-		determining when 'CET' supplanted 'MEZ' in common usage.
++    Use current abbreviations for older timestamps to avoid confusion.
++    For example, in 1910 a common English abbreviation for time
++    in central Europe was 'MEZ' (short for both "Middle European
++    Zone" and for "Mitteleuropäische Zeit" in German).
++    Nowadays 'CET' ("Central European Time") is more common in
++    English, and the database uses 'CET' even for circa-1910
++    timestamps as this is less confusing for modern users and avoids
++    the need for determining when 'CET' supplanted 'MEZ' in common
++    usage.
+   </li>
+   <li>
+-	Use a consistent style in a zone's history.  For example, if a zone's
+-		history tends to use numeric abbreviations and a particular
+-		entry could go either way, use a numeric abbreviation.
++    Use a consistent style in a <code><abbr>tz</abbr></code> region's history.
++    For example, if history tends to use numeric
++    abbreviations and a particular entry could go either way, use a
++    numeric abbreviation.
+   </li>
+   <li>
+-	Use UT (with time zone abbreviation '<code>-</code>00') for
+-		locations while uninhabited.  The leading
+-		'<code>-</code>' is a flag that the time
+-		zone is in some sense undefined; this notation is
+-		derived from Internet RFC 3339.
++    Use
++    <a href="https://en.wikipedia.org/wiki/Universal_Time">Universal Time</a>
++    (<abbr>UT</abbr>) (with time zone abbreviation '<code>-</code>00') for
++    locations while uninhabited.
++    The leading '<code>-</code>' is a flag that the <abbr>UT</abbr> offset is in
++    some sense undefined; this notation is derived
++    from <a href="https://tools.ietf.org/html/rfc3339">Internet
++    <abbr title="Request For Comments">RFC 3339</a>.
+   </li>
+ </ul>
++
+ <p>
+ Application writers should note that these abbreviations are ambiguous
+ in practice: e.g., 'CST' means one thing in China and something else
+ in North America, and 'IST' can refer to time in India, Ireland or
+-Israel. To avoid ambiguity, use numeric UT offsets like
++Israel.
++To avoid ambiguity, use numeric <abbr>UT</abbr> offsets like
+ '<code>-</code>0600' instead of time zone abbreviations like 'CST'.
+ </p>
+-  </section>
++</section>
+ 
+-
+-  <section>
+-    <h2 id="accuracy">Accuracy of the tz database</h2>
++<section>
++  <h2 id="accuracy">Accuracy of the <code><abbr>tz</abbr></code> database</h2>
+ <p>
+-The tz database is not authoritative, and it surely has errors.
++The <code><abbr>tz</abbr></code> database is not authoritative, and it
++surely has errors.
+ Corrections are welcome and encouraged; see the file <code>CONTRIBUTING</code>.
+ Users requiring authoritative data should consult national standards
+ bodies and the references cited in the database's comments.
+@@ -456,641 +513,775 @@
+ </p>
+ 
+ <p>
+-Errors in the tz database arise from many sources:
++Errors in the <code><abbr>tz</abbr></code> database arise from many sources:
+ </p>
++
+ <ul>
+   <li>
+-   The tz database predicts future timestamps, and current predictions
+-   will be incorrect after future governments change the rules.
+-   For example, if today someone schedules a meeting for 13:00 next
+-   October 1, Casablanca time, and tomorrow Morocco changes its
+-   daylight saving rules, software can mess up after the rule change
+-   if it blithely relies on conversions made before the change.
++    The <code><abbr>tz</abbr></code> database predicts future
++    timestamps, and current predictions
++    will be incorrect after future governments change the rules.
++    For example, if today someone schedules a meeting for 13:00 next
++    October 1, Casablanca time, and tomorrow Morocco changes its
++    daylight saving rules, software can mess up after the rule change
++    if it blithely relies on conversions made before the change.
+   </li>
+   <li>
+-   The pre-1970 entries in this database cover only a tiny sliver of how
+-   clocks actually behaved; the vast majority of the necessary
+-   information was lost or never recorded.  Thousands more zones would
+-   be needed if the tz database's scope were extended to cover even
+-   just the known or guessed history of standard time; for example,
+-   the current single entry for France would need to split into dozens
+-   of entries, perhaps hundreds.  And in most of the world even this
+-   approach would be misleading due to widespread disagreement or
+-   indifference about what times should be observed.  In her 2015 book
+-   <cite>The Global Transformation of Time, 1870-1950</cite>, Vanessa Ogle writes
+-   "Outside of Europe and North America there was no system of time
+-   zones at all, often not even a stable landscape of mean times,
+-   prior to the middle decades of the twentieth century".  See:
+-   Timothy Shenk, <a
+-   href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanessa-ogle">Booked:
+-   A Global History of Time</a>. <cite>Dissent</cite> 2015-12-17.
++    The pre-1970 entries in this database cover only a tiny sliver of how
++    clocks actually behaved; the vast majority of the necessary
++    information was lost or never recorded.
++    Thousands more <code><abbr>tz</abbr></code> regions would be needed if
++    the <code><abbr>tz</abbr></code> database's scope were extended to
++    cover even just the known or guessed history of standard time; for
++    example, the current single entry for France would need to split
++    into dozens of entries, perhaps hundreds.
++    And in most of the world even this approach would be misleading
++    due to widespread disagreement or indifference about what times
++    should be observed.
++    In her 2015 book
++    <cite><a
++    href="http://www.hup.harvard.edu/catalog.php?isbn=9780674286146">The
++    Global Transformation of Time, 1870&ndash;1950</a></cite>,
++    Vanessa Ogle writes
++    "Outside of Europe and North America there was no system of time
++    zones at all, often not even a stable landscape of mean times,
++    prior to the middle decades of the twentieth century".
++    See: Timothy Shenk, <a
++href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanessa-ogle">Booked:
++      A Global History of Time</a>. <cite>Dissent</cite> 2015-12-17.
+   </li>
+   <li>
+-   Most of the pre-1970 data entries come from unreliable sources, often
+-   astrology books that lack citations and whose compilers evidently
+-   invented entries when the true facts were unknown, without
+-   reporting which entries were known and which were invented.
+-   These books often contradict each other or give implausible entries,
+-   and on the rare occasions when they are checked they are
+-   typically found to be incorrect.
++    Most of the pre-1970 data entries come from unreliable sources, often
++    astrology books that lack citations and whose compilers evidently
++    invented entries when the true facts were unknown, without
++    reporting which entries were known and which were invented.
++    These books often contradict each other or give implausible entries,
++    and on the rare occasions when they are checked they are
++    typically found to be incorrect.
+   </li>
+   <li>
+-   For the UK the tz database relies on years of first-class work done by
+-   Joseph Myers and others; see
+-   "<a href="https://www.polyomino.org.uk/british-time/">History of
+-   legal time in Britain</a>".
+-   Other countries are not done nearly as well.
++    For the UK the <code><abbr>tz</abbr></code> database relies on
++    years of first-class work done by
++    Joseph Myers and others; see
++    "<a href="https://www.polyomino.org.uk/british-time/">History of
++    legal time in Britain</a>".
++    Other countries are not done nearly as well.
+   </li>
+   <li>
+-   Sometimes, different people in the same city would maintain clocks
+-   that differed significantly.  Railway time was used by railroad
+-   companies (which did not always agree with each other),
+-   church-clock time was used for birth certificates, etc.
+-   Often this was merely common practice, but sometimes it was set by law.
+-   For example, from 1891 to 1911 the UT offset in France was legally
+-   0:09:21 outside train stations and 0:04:21 inside.
++    Sometimes, different people in the same city maintain clocks
++    that differ significantly.
++    Historically, railway time was used by railroad companies (which
++    did not always
++    agree with each other), church-clock time was used for birth
++    certificates, etc.
++    More recently, competing political groups might disagree about
++    clock settings. Often this is merely common practice, but
++    sometimes it is set by law.
++    For example, from 1891 to 1911 the <abbr>UT</abbr> offset in France
++    was legally <abbr>UT</abbr> +00:09:21 outside train stations and
++    <abbr>UT</abbr> +00:04:21 inside. Other examples include
++    Chillicothe in 1920, Palm Springs in 1946/7, and Jerusalem and
++    Ürümqi to this day.
+   </li>
+   <li>
+-   Although a named location in the tz database stands for the
+-   containing region, its pre-1970 data entries are often accurate for
+-   only a small subset of that region.  For example, <code>Europe/London</code>
+-   stands for the United Kingdom, but its pre-1847 times are valid
+-   only for locations that have London's exact meridian, and its 1847
+-   transition to GMT is known to be valid only for the L&amp;NW and the
+-   Caledonian railways.
++    Although a named location in the <code><abbr>tz</abbr></code>
++    database stands for the containing region, its pre-1970 data
++    entries are often accurate for only a small subset of that region.
++    For example, <code>Europe/London</code> stands for the United
++    Kingdom, but its pre-1847 times are valid only for locations that
++    have London's exact meridian, and its 1847 transition
++    to <abbr>GMT</abbr> is known to be valid only for the L&amp;NW and
++    the Caledonian railways.
+   </li>
+   <li>
+-   The tz database does not record the earliest time for which a zone's
+-   data entries are thereafter valid for every location in the region.
+-   For example, <code>Europe/London</code> is valid for all locations in its
+-   region after GMT was made the standard time, but the date of
+-   standardization (1880-08-02) is not in the tz database, other than
+-   in commentary.  For many zones the earliest time of validity is
+-   unknown.
++    The <code><abbr>tz</abbr></code> database does not record the
++    earliest time for which a <code><abbr>tz</abbr></code> region's
++    data entries are thereafter valid for every location in the region.
++    For example, <code>Europe/London</code> is valid for all locations
++    in its region after <abbr>GMT</abbr> was made the standard time,
++    but the date of standardization (1880-08-02) is not in the
++    <code><abbr>tz</abbr></code> database, other than in commentary.
++    For many <code><abbr>tz</abbr></code> regions the earliest time of
++    validity is unknown.
+   </li>
+   <li>
+-   The tz database does not record a region's boundaries, and in many
+-   cases the boundaries are not known.  For example, the zone
+-   <code>America/Kentucky/Louisville</code> represents a region around
+-   the city of
+-   Louisville, the boundaries of which are unclear.
++    The <code><abbr>tz</abbr></code> database does not record a
++    region's boundaries, and in many cases the boundaries are not known.
++    For example, the <code><abbr>tz</abbr></code> region
++    <code>America/Kentucky/Louisville</code> represents a region
++    around the city of Louisville, the boundaries of which are
++    unclear.
+   </li>
+   <li>
+-   Changes that are modeled as instantaneous transitions in the tz
+-   database were often spread out over hours, days, or even decades.
++    Changes that are modeled as instantaneous transitions in the
++    <code><abbr>tz</abbr></code>
++    database were often spread out over hours, days, or even decades.
+   </li>
+   <li>
+-   Even if the time is specified by law, locations sometimes
+-   deliberately flout the law.
++    Even if the time is specified by law, locations sometimes
++    deliberately flout the law.
+   </li>
+   <li>
+-   Early timekeeping practices, even assuming perfect clocks, were
+-   often not specified to the accuracy that the tz database requires.
++    Early timekeeping practices, even assuming perfect clocks, were
++    often not specified to the accuracy that the
++    <code><abbr>tz</abbr></code> database requires.
+   </li>
+   <li>
+-   Sometimes historical timekeeping was specified more precisely
+-   than what the tz database can handle.  For example, from 1909 to
+-   1937 Netherlands clocks were legally UT +00:19:32.13, but the tz
+-   database cannot represent the fractional second.
++    Sometimes historical timekeeping was specified more precisely
++    than what the <code><abbr>tz</abbr></code> code can handle.
++    For example, from 1909 to 1937 <a
++    href="https://www.staff.science.uu.nl/~gent0113/wettijd/wettijd.htm"
++    hreflang="nl">Netherlands clocks</a> were legally Amsterdam Mean
++    Time (estimated to be <abbr>UT</abbr>
++    +00:19:32.13), but the <code><abbr>tz</abbr></code>
++    code cannot represent the fractional second.
++    In practice these old specifications were rarely if ever
++    implemented to subsecond precision.
+   </li>
+   <li>
+-   Even when all the timestamp transitions recorded by the tz database
+-   are correct, the tz rules that generate them may not faithfully
+-   reflect the historical rules.  For example, from 1922 until World
+-   War II the UK moved clocks forward the day following the third
+-   Saturday in April unless that was Easter, in which case it moved
+-   clocks forward the previous Sunday.  Because the tz database has no
+-   way to specify Easter, these exceptional years are entered as
+-   separate tz Rule lines, even though the legal rules did not change.
++    Even when all the timestamp transitions recorded by the
++    <code><abbr>tz</abbr></code> database are correct, the
++    <code><abbr>tz</abbr></code> rules that generate them may not
++    faithfully reflect the historical rules.
++    For example, from 1922 until World War II the UK moved clocks
++    forward the day following the third Saturday in April unless that
++    was Easter, in which case it moved clocks forward the previous
++    Sunday.
++    Because the <code><abbr>tz</abbr></code> database has no
++    way to specify Easter, these exceptional years are entered as
++    separate <code><abbr>tz</abbr> Rule</code> lines, even though the
++    legal rules did not change.
+   </li>
+   <li>
+-   The tz database models pre-standard time using the proleptic Gregorian
+-   calendar and local mean time (LMT), but many people used other
+-   calendars and other timescales.  For example, the Roman Empire used
+-   the Julian calendar, and had 12 varying-length daytime hours with a
+-   non-hour-based system at night.
++    The <code><abbr>tz</abbr></code> database models pre-standard time
++    using the <a
++    href="https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar">proleptic
++    Gregorian calendar</a> and local mean time, but many people used
++    other calendars and other timescales.
++    For example, the Roman Empire used
++    the <a href="https://en.wikipedia.org/wiki/Julian_calendar">Julian
++    calendar</a>,
++    and <a href="https://en.wikipedia.org/wiki/Roman_timekeeping">Roman
++    timekeeping</a> had twelve varying-length daytime hours with a
++    non-hour-based system at night.
+   </li>
+   <li>
+-   Early clocks were less reliable, and data entries do not represent
+-   clock error.
++    Early clocks were less reliable, and data entries do not represent
++    clock error.
+   </li>
+   <li>
+-   The tz database assumes Universal Time (UT) as an origin, even
+-   though UT is not standardized for older timestamps.  In the tz
+-   database commentary, UT denotes a family of time standards that
+-   includes Coordinated Universal Time (UTC) along with other variants
+-   such as UT1 and GMT, with days starting at midnight.  Although UT
+-   equals UTC for modern timestamps, UTC was not defined until 1960,
+-   so commentary uses the more-general abbreviation UT for timestamps
+-   that might predate 1960.  Since UT, UT1, etc. disagree slightly,
+-   and since pre-1972 UTC seconds varied in length, interpretation of
+-   older timestamps can be problematic when subsecond accuracy is
+-   needed.
++    The <code><abbr>tz</abbr></code> database assumes Universal Time
++    (<abbr>UT</abbr>) as an origin, even though <abbr>UT</abbr> is not
++    standardized for older timestamps.
++    In the <code><abbr>tz</abbr></code> database commentary,
++    <abbr>UT</abbr> denotes a family of time standards that includes
++    Coordinated Universal Time (<abbr>UTC</abbr>) along with other
++    variants such as <abbr>UT1</abbr> and <abbr>GMT</abbr>,
++    with days starting at midnight.
++    Although <abbr>UT</abbr> equals <abbr>UTC</abbr> for modern
++    timestamps, <abbr>UTC</abbr> was not defined until 1960, so
++    commentary uses the more-general abbreviation <abbr>UT</abbr> for
++    timestamps that might predate 1960.
++    Since <abbr>UT</abbr>, <abbr>UT1</abbr>, etc. disagree slightly,
++    and since pre-1972 <abbr>UTC</abbr> seconds varied in length,
++    interpretation of older timestamps can be problematic when
++    subsecond accuracy is needed.
+   </li>
+   <li>
+-   Civil time was not based on atomic time before 1972, and we don't
+-   know the history of earth's rotation accurately enough to map SI
+-   seconds to historical solar time to more than about one-hour
+-   accuracy.  See: Stephenson FR, Morrison LV, Hohenkerk CY.
+-   <a href="http://dx.doi.org/10.1098/rspa.2016.0404">Measurement
+-   of the Earth's rotation: 720 BC to AD 2015</a>.
+-   <cite>Proc Royal Soc A</cite>. 2016 Dec 7;472:20160404.
+-   Also see: Espenak F. <a
+-   href="https://eclipse.gsfc.nasa.gov/SEhelp/uncertainty2004.html">Uncertainty
+-   in Delta T (ΔT)</a>.
++    Civil time was not based on atomic time before 1972, and we don't
++    know the history of
++    <a href="https://en.wikipedia.org/wiki/Earth's_rotation">earth's
++    rotation</a> accurately enough to map <a
++    href="https://en.wikipedia.org/wiki/International_System_of_Units"><abbr
++    title="International System of Units">SI</abbr></a> seconds to
++    historical <a href="https://en.wikipedia.org/wiki/Solar_time">solar time</a>
++    to more than about one-hour accuracy.
++    See: Stephenson FR, Morrison LV, Hohenkerk CY.
++    <a href="http://dx.doi.org/10.1098/rspa.2016.0404">Measurement of
++    the Earth's rotation: 720 BC to AD 2015</a>.
++    <cite>Proc Royal Soc A</cite>. 2016 Dec 7;472:20160404.
++    Also see: Espenak F. <a
++    href="https://eclipse.gsfc.nasa.gov/SEhelp/uncertainty2004.html">Uncertainty
++    in Delta T (ΔT)</a>.
+   </li>
+   <li>
+-   The relationship between POSIX time (that is, UTC but ignoring leap
+-   seconds) and UTC is not agreed upon after 1972.  Although the POSIX
+-   clock officially stops during an inserted leap second, at least one
+-   proposed standard has it jumping back a second instead; and in
+-   practice POSIX clocks more typically either progress glacially during
+-   a leap second, or are slightly slowed while near a leap second.
++    The relationship between POSIX time (that is, <abbr>UTC</abbr> but
++    ignoring <a href="https://en.wikipedia.org/wiki/Leap_second">leap
++    seconds</a>) and <abbr>UTC</abbr> is not agreed upon after 1972.
++    Although the POSIX
++    clock officially stops during an inserted leap second, at least one
++    proposed standard has it jumping back a second instead; and in
++    practice POSIX clocks more typically either progress glacially during
++    a leap second, or are slightly slowed while near a leap second.
+   </li>
+   <li>
+-   The tz database does not represent how uncertain its information is.
+-   Ideally it would contain information about when data entries are
+-   incomplete or dicey.  Partial temporal knowledge is a field of
+-   active research, though, and it's not clear how to apply it here.
++    The <code><abbr>tz</abbr></code> database does not represent how
++    uncertain its information is.
++    Ideally it would contain information about when data entries are
++    incomplete or dicey.
++    Partial temporal knowledge is a field of active research, though,
++    and it's not clear how to apply it here.
+   </li>
+ </ul>
++
+ <p>
+-In short, many, perhaps most, of the tz database's pre-1970 and future
+-timestamps are either wrong or misleading.  Any attempt to pass the
+-tz database off as the definition of time should be unacceptable to
+-anybody who cares about the facts.  In particular, the tz database's
+-LMT offsets should not be considered meaningful, and should not prompt
+-creation of zones merely because two locations differ in LMT or
+-transitioned to standard time at different dates.
++In short, many, perhaps most, of the <code><abbr>tz</abbr></code>
++database's pre-1970 and future timestamps are either wrong or
++misleading.
++Any attempt to pass the
++<code><abbr>tz</abbr></code> database off as the definition of time
++should be unacceptable to anybody who cares about the facts.
++In particular, the <code><abbr>tz</abbr></code> database's
++<abbr>LMT</abbr> offsets should not be considered meaningful, and
++should not prompt creation of <code><abbr>tz</abbr></code> regions
++merely because two locations
++differ in <abbr>LMT</abbr> or transitioned to standard time at
++different dates.
+ </p>
+-  </section>
++</section>
+ 
+-
+-  <section>
+-    <h2 id="functions">Time and date functions</h2>
++<section>
++  <h2 id="functions">Time and date functions</h2>
+ <p>
+-The tz code contains time and date functions that are upwards
+-compatible with those of POSIX.
++The <code><abbr>tz</abbr></code> code contains time and date functions
++that are upwards compatible with those of POSIX.
++Code compatible with this package is already
++<a href="tz-link.html#tzdb">part of many platforms</a>, where the
++primary use of this package is to update obsolete time-related files.
++To do this, you may need to compile the time zone compiler
++'<code>zic</code>' supplied with this package instead of using the
++system '<code>zic</code>', since the format of <code>zic</code>'s
++input is occasionally extended, and a platform may still be shipping
++an older <code>zic</code>.
+ </p>
+ 
+-<p>
+-POSIX has the following properties and limitations.
+-</p>
++<h3 id="POSIX">POSIX properties and limitations</h3>
+ <ul>
+   <li>
+     <p>
+-	In POSIX, time display in a process is controlled by the
+-	environment variable TZ.  Unfortunately, the POSIX TZ string takes
+-	a form that is hard to describe and is error-prone in practice.
+-	Also, POSIX TZ strings can't deal with other (for example, Israeli)
+-	daylight saving time rules, or situations where more than two
+-	time zone abbreviations are used in an area.
++    In POSIX, time display in a process is controlled by the
++    environment variable <code>TZ</code>.
++    Unfortunately, the POSIX
++    <code>TZ</code> string takes a form that is hard to describe and
++    is error-prone in practice.
++    Also, POSIX <code>TZ</code> strings can't deal with daylight
++    saving time rules not based on the Gregorian calendar (as in
++    Iran), or with situations where more than two time zone
++    abbreviations or <abbr>UT</abbr> offsets are used in an area.
+     </p>
++
+     <p>
+-      The POSIX TZ string takes the following form:
++    The POSIX <code>TZ</code> string takes the following form:
+     </p>
++
+     <p>
+-      <var>stdoffset</var>[<var>dst</var>[<var>offset</var>][<code>,</code><var>date</var>[<code>/</code><var>time</var>]<code>,</code><var>date</var>[<code>/</code><var>time</var>]]]
++    <var>stdoffset</var>[<var>dst</var>[<var>offset</var>][<code>,</code><var>date</var>[<code>/</code><var>time</var>]<code>,</code><var>date</var>[<code>/</code><var>time</var>]]]
+     </p>
++
+     <p>
+-	where:
++    where:
++    </p>
++
+     <dl>
+       <dt><var>std</var> and <var>dst</var></dt><dd>
+-		are 3 or more characters specifying the standard
+-		and daylight saving time (DST) zone names.
+-		Starting with POSIX.1-2001, <var>std</var>
+-		and <var>dst</var> may also be
+-		in a quoted form like '<code>&lt;+09&gt;</code>'; this allows
+-		"<code>+</code>" and "<code>-</code>" in the names.
++	are 3 or more characters specifying the standard
++	and daylight saving time (<abbr>DST</abbr>) zone names.
++	Starting with POSIX.1-2001, <var>std</var> and <var>dst</var>
++	may also be in a quoted form like '<code>&lt;+09&gt;</code>';
++	this allows "<code>+</code>" and "<code>-</code>" in the names.
+       </dd>
+       <dt><var>offset</var></dt><dd>
+-		is of the form
+-		'<code>[&plusmn;]<var>hh</var>:[<var>mm</var>[:<var>ss</var>]]</code>'
+-		and specifies the offset west of UT.  '<var>hh</var>'
+-		may be a single digit; 0&le;<var>hh</var>&le;24.
+-		The default DST offset is one hour ahead of standard time.
++	is of the form
++	'<code>[&plusmn;]<var>hh</var>:[<var>mm</var>[:<var>ss</var>]]</code>'
++	and specifies the offset west of <abbr>UT</abbr>.
++	'<var>hh</var>' may be a single digit;
++	0&le;<var>hh</var>&le;24.
++	The default <abbr>DST</abbr> offset is one hour ahead of
++	standard time.
+       </dd>
+       <dt><var>date</var>[<code>/</code><var>time</var>]<code>,</code><var>date</var>[<code>/</code><var>time</var>]</dt><dd>
+-		specifies the beginning and end of DST.  If this is absent,
+-		the system supplies its own rules for DST, and these can
+-		differ from year to year; typically US DST rules are used.
++	specifies the beginning and end of <abbr>DST</abbr>.
++	If this is absent, the system supplies its own ruleset
++	for <abbr>DST</abbr>, and its rules can differ from year to year;
++	typically <abbr>US</abbr> <abbr>DST</abbr> rules are used.
+       </dd>
+       <dt><var>time</var></dt><dd>
+-		takes the form
+-		'<var>hh</var><code>:</code>[<var>mm</var>[<code>:</code><var>ss</var>]]'
+-		and defaults to 02:00.
+-		This is the same format as the offset, except that a
+-		leading '<code>+</code>' or '<code>-</code>' is not allowed.
++	takes the form
++	'<var>hh</var><code>:</code>[<var>mm</var>[<code>:</code><var>ss</var>]]'
++	and defaults to 02:00.
++	This is the same format as the offset, except that a
++	leading '<code>+</code>' or '<code>-</code>' is not allowed.
+       </dd>
+       <dt><var>date</var></dt><dd>
+-		takes one of the following forms:
++	takes one of the following forms:
+ 	<dl>
+ 	  <dt>J<var>n</var> (1&le;<var>n</var>&le;365)</dt><dd>
+-			origin-1 day number not counting February 29
+-          </dd>
++	    origin-1 day number not counting February 29
++	  </dd>
+ 	  <dt><var>n</var> (0&le;<var>n</var>&le;365)</dt><dd>
+-			origin-0 day number counting February 29 if present
+-          </dd>
+-	  <dt><code>M</code><var>m</var><code>.</code><var>n</var><code>.</code><var>d</var> (0[Sunday]&le;<var>d</var>&le;6[Saturday], 1&le;<var>n</var>&le;5, 1&le;<var>m</var>&le;12)</dt><dd>
+-			for the <var>d</var>th day of
+-			week <var>n</var> of month <var>m</var> of the
+-			year, where week 1 is the first week in which
+-			day <var>d</var> appears, and '<code>5</code>'
+-			stands for the last week in which
+-			day <var>d</var> appears
+-			(which may be either the 4th or 5th week).
+-			Typically, this is the only useful form;
+-			the <var>n</var>
+-			and <code>J</code><var>n</var> forms are
+-			rarely used.
++	    origin-0 day number counting February 29 if present
+ 	  </dd>
+-</dl>
+-</dd>
+-</dl>
+-	Here is an example POSIX TZ string for New Zealand after 2007.
+-	It says that standard time (NZST) is 12 hours ahead of UT,
+-	and that daylight saving time (NZDT) is observed from September's
+-	last Sunday at 02:00 until April's first Sunday at 03:00:
++	  <dt><code>M</code><var>m</var><code>.</code><var>n</var><code>.</code><var>d</var>
++	    (0[Sunday]&le;<var>d</var>&le;6[Saturday], 1&le;<var>n</var>&le;5,
++	    1&le;<var>m</var>&le;12)</dt><dd>
++	    for the <var>d</var>th day of week <var>n</var> of
++	    month <var>m</var> of the year, where week 1 is the first
++	    week in which day <var>d</var> appears, and
++	    '<code>5</code>' stands for the last week in which
++	    day <var>d</var> appears (which may be either the 4th or
++	    5th week).
++	    Typically, this is the only useful form; the <var>n</var>
++	    and <code>J</code><var>n</var> forms are rarely used.
++	  </dd>
++	</dl>
++      </dd>
++    </dl>
+ 
+-        <pre><code>TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'</code></pre>
++    <p>
++    Here is an example POSIX <code>TZ</code> string for New
++    Zealand after 2007.
++    It says that standard time (<abbr>NZST</abbr>) is 12 hours ahead
++    of <abbr>UT</abbr>, and that daylight saving time
++    (<abbr>NZDT</abbr>) is observed from September's last Sunday at
++    02:00 until April's first Sunday at 03:00:
++    </p>
+ 
+-	This POSIX TZ string is hard to remember, and mishandles some
+-	timestamps before 2008.  With this package you can use this
+-	instead:
++    <pre><code>TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'</code></pre>
+ 
+-	<pre><code>TZ='Pacific/Auckland'</code></pre>
++    <p>
++    This POSIX <code>TZ</code> string is hard to remember, and
++    mishandles some timestamps before 2008.
++    With this package you can use this instead:
++    </p>
++
++    <pre><code>TZ='Pacific/Auckland'</code></pre>
+   </li>
+   <li>
+-	POSIX does not define the exact meaning of TZ values like
+-	"<code>EST5EDT</code>".
+-	Typically the current US DST rules are used to interpret such values,
+-	but this means that the US DST rules are compiled into each program
+-	that does time conversion.  This means that when US time conversion
+-	rules change (as in the United States in 1987), all programs that
+-	do time conversion must be recompiled to ensure proper results.
++    POSIX does not define the exact meaning of <code>TZ</code> values like
++    "<code>EST5EDT</code>".
++    Typically the current <abbr>US</abbr> <abbr>DST</abbr> rules
++    are used to interpret such values, but this means that the
++    <abbr>US</abbr> <abbr>DST</abbr> rules are compiled into each
++    program that does time conversion.
++    This means that when
++    <abbr>US</abbr> time conversion rules change (as in the United
++    States in 1987), all programs that do time conversion must be
++    recompiled to ensure proper results.
+   </li>
+   <li>
+-	The TZ environment variable is process-global, which makes it hard
+-	to write efficient, thread-safe applications that need access
+-	to multiple time zones.
++    The <code>TZ</code> environment variable is process-global, which
++    makes it hard to write efficient, thread-safe applications that
++    need access to multiple time zone rulesets.
+   </li>
+   <li>
+-	In POSIX, there's no tamper-proof way for a process to learn the
+-	system's best idea of local wall clock.  (This is important for
+-	applications that an administrator wants used only at certain
+-	times &ndash;
+-	without regard to whether the user has fiddled the TZ environment
+-	variable.  While an administrator can "do everything in UT" to get
+-	around the problem, doing so is inconvenient and precludes handling
+-	daylight saving time shifts - as might be required to limit phone
+-	calls to off-peak hours.)
++    In POSIX, there's no tamper-proof way for a process to learn the
++    system's best idea of local wall clock.
++    (This is important for applications that an administrator wants
++    used only at certain times &ndash; without regard to whether the
++    user has fiddled the
++    <code>TZ</code> environment variable.
++    While an administrator can "do everything in <abbr>UT</abbr>" to
++    get around the problem, doing so is inconvenient and precludes
++    handling daylight saving time shifts - as might be required to
++    limit phone calls to off-peak hours.)
+   </li>
+   <li>
+-	POSIX provides no convenient and efficient way to determine the UT
+-	offset and time zone abbreviation of arbitrary timestamps,
+-	particularly for time zone settings that do not fit into the
+-	POSIX model.
++    POSIX provides no convenient and efficient way to determine
++    the <abbr>UT</abbr> offset and time zone abbreviation of arbitrary
++    timestamps, particularly for <code><abbr>tz</abbr></code> regions
++    that do not fit into the POSIX model.
+   </li>
+   <li>
+-	POSIX requires that systems ignore leap seconds.
++    POSIX requires that systems ignore leap seconds.
+   </li>
+   <li>
+-	The tz code attempts to support all the <code>time_t</code>
+-	implementations allowed by POSIX.  The <code>time_t</code>
+-	type represents a nonnegative count of
+-	seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds.
+-	In practice, <code>time_t</code> is usually a signed 64- or
+-	32-bit integer; 32-bit signed <code>time_t</code> values stop
+-	working after 2038-01-19 03:14:07 UTC, so
+-	new implementations these days typically use a signed 64-bit integer.
+-	Unsigned 32-bit integers are used on one or two platforms,
+-	and 36-bit and 40-bit integers are also used occasionally.
+-	Although earlier POSIX versions allowed <code>time_t</code> to be a
+-	floating-point type, this was not supported by any practical
+-	systems, and POSIX.1-2013 and the tz code both
+-	require <code>time_t</code>
+-	to be an integer type.
++    The <code><abbr>tz</abbr></code> code attempts to support all the
++    <code>time_t</code> implementations allowed by POSIX.
++    The <code>time_t</code> type represents a nonnegative count of seconds
++    since 1970-01-01 00:00:00 <abbr>UTC</abbr>, ignoring leap seconds.
++    In practice, <code>time_t</code> is usually a signed 64- or 32-bit
++    integer; 32-bit signed <code>time_t</code> values stop working after
++    2038-01-19 03:14:07 <abbr>UTC</abbr>, so new implementations these
++    days typically use a signed 64-bit integer.
++    Unsigned 32-bit integers are used on one or two platforms, and 36-bit
++    and 40-bit integers are also used occasionally.
++    Although earlier POSIX versions allowed <code>time_t</code> to be a
++    floating-point type, this was not supported by any practical systems,
++    and POSIX.1-2013 and the <code><abbr>tz</abbr></code> code both
++    require <code>time_t</code> to be an integer type.
+   </li>
+ </ul>
+-<p>
+-These are the extensions that have been made to the POSIX functions:
+-</p>
++
++<h3 id="POSIX-extensions">Extensions to POSIX in the
++<code><abbr>tz</abbr></code> code</h3>
+ <ul>
+   <li>
+     <p>
+-	The TZ environment variable is used in generating the name of a file
+-	from which time zone information is read (or is interpreted a la
+-	POSIX); TZ is no longer constrained to be a three-letter time zone
+-	name followed by a number of hours and an optional three-letter
+-	daylight time zone name.  The daylight saving time rules to be used
+-	for a particular time zone are encoded in the time zone file;
+-	the format of the file allows U.S., Australian, and other rules to be
+-	encoded, and allows for situations where more than two time zone
+-	abbreviations are used.
++    The <code>TZ</code> environment variable is used in generating
++    the name of a binary file from which time-related information is read
++    (or is interpreted à la POSIX); <code>TZ</code> is no longer
++    constrained to be a three-letter time zone
++    abbreviation followed by a number of hours and an optional three-letter
++    daylight time zone abbreviation.
++    The daylight saving time rules to be used for a
++    particular <code><abbr>tz</abbr></code> region are encoded in the
++    binary file; the format of the file
++    allows U.S., Australian, and other rules to be encoded, and
++    allows for situations where more than two time zone
++    abbreviations are used.
+     </p>
+     <p>
+-	It was recognized that allowing the TZ environment variable to
+-	take on values such as '<code>America/New_York</code>' might
+-	cause "old" programs
+-	(that expect TZ to have a certain form) to operate incorrectly;
+-	consideration was given to using some other environment variable
+-	(for example, TIMEZONE) to hold the string used to generate the
+-	time zone information file name.  In the end, however, it was decided
+-	to continue using TZ: it is widely used for time zone purposes;
+-	separately maintaining both TZ and TIMEZONE seemed a nuisance;
+-	and systems where "new" forms of TZ might cause problems can simply
+-	use TZ values such as "<code>EST5EDT</code>" which can be used both by
+-	"new" programs (a la POSIX) and "old" programs (as zone names and
+-	offsets).
++    It was recognized that allowing the <code>TZ</code> environment
++    variable to take on values such as '<code>America/New_York</code>'
++    might cause "old" programs (that expect <code>TZ</code> to have a
++    certain form) to operate incorrectly; consideration was given to using
++    some other environment variable (for example, <code>TIMEZONE</code>)
++    to hold the string used to generate the binary file's name.
++    In the end, however, it was decided to continue using
++    <code>TZ</code>: it is widely used for time zone purposes;
++    separately maintaining both <code>TZ</code>
++    and <code>TIMEZONE</code> seemed a nuisance; and systems where
++    "new" forms of <code>TZ</code> might cause problems can simply
++    use <code>TZ</code> values such as "<code>EST5EDT</code>" which
++    can be used both by "new" programs (à la POSIX) and "old"
++    programs (as zone names and offsets).
+     </p>
+-</li>
+-<li>
+-	The code supports platforms with a UT offset member
+-	in <code>struct tm</code>,
+-	e.g., <code>tm_gmtoff</code>.
+-</li>
+-<li>
+-	The code supports platforms with a time zone abbreviation member in
+-	<code>struct tm</code>, e.g., <code>tm_zone</code>.
+-</li>
+-<li>
+-	Since the TZ environment variable can now be used to control time
+-	conversion, the <code>daylight</code>
+-	and <code>timezone</code> variables are no longer needed.
+-	(These variables are defined and set by <code>tzset</code>;
+-	however, their values will not be used
+-	by <code>localtime</code>.)
+-</li>
+-<li>
+-	Functions <code>tzalloc</code>, <code>tzfree</code>,
+-	<code>localtime_rz</code>, and <code>mktime_z</code> for
+-	more-efficient thread-safe applications that need to use
+-	multiple time zones.  The <code>tzalloc</code>
+-	and <code>tzfree</code> functions allocate and free objects of
+-	type <code>timezone_t</code>, and <code>localtime_rz</code>
+-	and <code>mktime_z</code> are like <code>localtime_r</code>
+-	and <code>mktime</code> with an extra
+-	<code>timezone_t</code> argument.  The functions were inspired
+-	by NetBSD.
+-</li>
+-<li>
+-	A function <code>tzsetwall</code> has been added to arrange
+-	for the system's
+-	best approximation to local wall clock time to be delivered by
+-	subsequent calls to <code>localtime</code>.  Source code for portable
+-	applications that "must" run on local wall clock time should call
+-	<code>tzsetwall</code>; if such code is moved to "old" systems that don't
+-	provide tzsetwall, you won't be able to generate an executable program.
+-	(These time zone functions also arrange for local wall clock time to be
+-	used if tzset is called &ndash; directly or indirectly &ndash;
+-	and there's no TZ
+-	environment variable; portable applications should not, however, rely
+-	on this behavior since it's not the way SVR2 systems behave.)
+-</li>
+-<li>
+-	Negative <code>time_t</code> values are supported, on systems
+-	where <code>time_t</code> is signed.
+-</li>
+-<li>
+-	These functions can account for leap seconds, thanks to Bradley White.
+-</li>
++  </li>
++  <li>
++    The code supports platforms with a <abbr>UT</abbr> offset member
++    in <code>struct tm</code>, e.g., <code>tm_gmtoff</code>.
++  </li>
++  <li>
++    The code supports platforms with a time zone abbreviation member in
++    <code>struct tm</code>, e.g., <code>tm_zone</code>.
++  </li>
++  <li>
++    Functions <code>tzalloc</code>, <code>tzfree</code>,
++    <code>localtime_rz</code>, and <code>mktime_z</code> for
++    more-efficient thread-safe applications that need to use multiple
++    time zone rulesets.
++    The <code>tzalloc</code> and <code>tzfree</code> functions
++    allocate and free objects of type <code>timezone_t</code>,
++    and <code>localtime_rz</code> and <code>mktime_z</code> are
++    like <code>localtime_r</code> and <code>mktime</code> with an
++    extra <code>timezone_t</code> argument.
++    The functions were inspired by <a href="https://netbsd.org/">NetBSD</a>.
++  </li>
++  <li>
++    A function <code>tzsetwall</code> has been added to arrange for the
++    system's best approximation to local wall clock time to be delivered
++    by subsequent calls to <code>localtime</code>.
++    Source code for portable applications that "must" run on local wall
++    clock time should call <code>tzsetwall</code>;
++    if such code is moved to "old" systems that don't
++    provide <code>tzsetwall</code>, you won't be able to generate an
++    executable program.
++    (These functions also arrange for local wall clock time to
++    be used if <code>tzset</code> is called &ndash; directly or
++    indirectly &ndash; and there's no <code>TZ</code> environment
++    variable; portable applications should not, however, rely on this
++    behavior since it's not the way SVR2 systems behave.)
++  </li>
++  <li>
++    Negative <code>time_t</code> values are supported, on systems
++    where <code>time_t</code> is signed.
++  </li>
++  <li>
++    These functions can account for leap seconds, thanks to Bradley White.
++  </li>
+ </ul>
++
++<h3 id="vestigial">POSIX features no longer needed</h3>
+ <p>
+-Points of interest to folks with other systems:
++POSIX and <a href="https://en.wikipedia.org/wiki/ISO_C"><abbr>ISO</abbr> C</a>
++define some <a href="https://en.wikipedia.org/wiki/API"><abbr
++title="application programming interface">API</abbr>s</a> that are vestigial:
++they are not needed, and are relics of a too-simple model that does
++not suffice to handle many real-world timestamps.
++Although the <code><abbr>tz</abbr></code> code supports these
++vestigial <abbr>API</abbr>s for backwards compatibility, they should
++be avoided in portable applications.
++The vestigial <abbr>API</abbr>s are:
+ </p>
+ <ul>
+   <li>
+-	Code compatible with this package is already part of many platforms,
+-	including GNU/Linux, Android, the BSDs, Chromium OS, Cygwin, AIX, iOS,
+-	BlackBery 10, macOS, Microsoft Windows, OpenVMS, and Solaris.
+-	On such hosts, the primary use of this package
+-	is to update obsolete time zone rule tables.
+-	To do this, you may need to compile the time zone compiler
+-	'<code>zic</code>' supplied with this package instead of using
+-	the system '<code>zic</code>', since the format
+-	of <code>zic</code>'s input is occasionally extended, and a
+-	platform may still be shipping an older <code>zic</code>.
++    The POSIX <code>tzname</code> variable does not suffice and is no
++    longer needed.
++    To get a timestamp's time zone abbreviation, consult
++    the <code>tm_zone</code> member if available; otherwise,
++    use <code>strftime</code>'s <code>"%Z"</code> conversion
++    specification.
+   </li>
+   <li>
+-	The UNIX Version 7 <code>timezone</code> function is not
+-	present in this package;
+-	it's impossible to reliably map timezone's arguments (a "minutes west
+-	of GMT" value and a "daylight saving time in effect" flag) to a
+-	time zone abbreviation, and we refuse to guess.
+-	Programs that in the past used the timezone function may now examine
+-	<code>localtime(&amp;clock)-&gt;tm_zone</code>
+-	(if <code>TM_ZONE</code> is defined) or
+-	<code>tzname[localtime(&amp;clock)-&gt;tm_isdst]</code>
+-	(if <code>HAVE_TZNAME</code> is defined)
+-	to learn the correct time zone abbreviation to use.
++    The POSIX <code>daylight</code> and <code>timezone</code>
++    variables do not suffice and are no longer needed.
++    To get a timestamp's <abbr>UT</abbr> offset, consult
++    the <code>tm_gmtoff</code> member if available; otherwise,
++    subtract values returned by <code>localtime</code>
++    and <code>gmtime</code> using the rules of the Gregorian calendar,
++    or use <code>strftime</code>'s <code>"%z"</code> conversion
++    specification if a string like <code>"+0900"</code> suffices.
+   </li>
+   <li>
+-	The 4.2BSD <code>gettimeofday</code> function is not used in
+-	this package.
+-	This formerly let users obtain the current UTC offset and DST flag,
+-	but this functionality was removed in later versions of BSD.
++    The <code>tm_isdst</code> member is almost never needed and most of
++    its uses should be discouraged in favor of the abovementioned
++    <abbr>API</abbr>s.
++    Although it can still be used in arguments to
++    <code>mktime</code> to disambiguate timestamps near
++    a <abbr>DST</abbr> transition when the clock jumps back, this
++    disambiguation does not work when standard time itself jumps back,
++    which can occur when a location changes to a time zone with a
++    lesser <abbr>UT</abbr> offset.
+   </li>
++</ul>
++
++<h3 id="other-portability">Other portability notes</h3>
++<ul>
+   <li>
+-	In SVR2, time conversion fails for near-minimum or near-maximum
+-	<code>time_t</code> values when doing conversions for places
+-	that don't use UT.
+-	This package takes care to do these conversions correctly.
+-	A comment in the source code tells how to get compatibly wrong
+-	results.
++    The <a href="https://en.wikipedia.org/wiki/Version_7_Unix">7th Edition
++    UNIX</a> <code>timezone</code> function is not present in this
++    package; it's impossible to reliably map <code>timezone</code>'s
++    arguments (a "minutes west of <abbr>GMT</abbr>" value and a
++    "daylight saving time in effect" flag) to a time zone
++    abbreviation, and we refuse to guess.
++    Programs that in the past used the <code>timezone</code> function
++    may now examine <code>localtime(&amp;clock)-&gt;tm_zone</code>
++    (if <code>TM_ZONE</code> is defined) or
++    <code>tzname[localtime(&amp;clock)-&gt;tm_isdst]</code>
++    (if <code>HAVE_TZNAME</code> is defined) to learn the correct time
++    zone abbreviation to use.
+   </li>
++  <li>
++    The <abbr>4.2BSD</abbr> <code>gettimeofday</code> function is not
++    used in this package.
++    This formerly let users obtain the current <abbr>UTC</abbr> offset
++    and <abbr>DST</abbr> flag, but this functionality was removed in
++    later versions of <abbr>BSD</abbr>.
++  </li>
++  <li>
++    In <abbr>SVR2</abbr>, time conversion fails for near-minimum or
++    near-maximum <code>time_t</code> values when doing conversions
++    for places that don't use <abbr>UT</abbr>.
++    This package takes care to do these conversions correctly.
++    A comment in the source code tells how to get compatibly wrong
++    results.
++  </li>
++  <li>
++    The functions that are conditionally compiled
++    if <code>STD_INSPIRED</code> is defined should, at this point, be
++    looked on primarily as food for thought.
++    They are not in any sense "standard compatible" &ndash; some are
++    not, in fact, specified in <em>any</em> standard.
++    They do, however, represent responses of various authors to
++    standardization proposals.
++  </li>
++  <li>
++    Other time conversion proposals, in particular the one developed
++    by folks at Hewlett Packard, offer a wider selection of functions
++    that provide capabilities beyond those provided here.
++    The absence of such functions from this package is not meant to
++    discourage the development, standardization, or use of such
++    functions.
++    Rather, their absence reflects the decision to make this package
++    contain valid extensions to POSIX, to ensure its broad
++    acceptability.
++    If more powerful time conversion functions can be standardized, so
++    much the better.
++  </li>
+ </ul>
+-<p>
+-The functions that are conditionally compiled
+-if <code>STD_INSPIRED</code> is defined
+-should, at this point, be looked on primarily as food for thought.  They are
+-not in any sense "standard compatible" &ndash; some are not, in fact,
+-specified in <em>any</em> standard.  They do, however, represent responses of
+-various authors to
+-standardization proposals.
+-</p>
++</section>
+ 
++<section>
++  <h2 id="stability">Interface stability</h2>
+ <p>
+-Other time conversion proposals, in particular the one developed by folks at
+-Hewlett Packard, offer a wider selection of functions that provide capabilities
+-beyond those provided here.  The absence of such functions from this package
+-is not meant to discourage the development, standardization, or use of such
+-functions.  Rather, their absence reflects the decision to make this package
+-contain valid extensions to POSIX, to ensure its broad acceptability.  If
+-more powerful time conversion functions can be standardized, so much the
+-better.
++The <code><abbr>tz</abbr></code> code and data supply the following interfaces:
+ </p>
+-  </section>
+ 
+-
+-  <section>
+-    <h2 id="stability">Interface stability</h2>
+-<p>
+-The tz code and data supply the following interfaces:
+-</p>
+ <ul>
+   <li>
+-   A set of zone names as per "<a href="#naming">Names of time zone
+-   rules</a>" above.
++    A set of <code><abbr>tz</abbr></code> region names as per
++      "<a href="#naming">Names of time zone rulesets</a>" above.
+   </li>
+   <li>
+-   Library functions described in "<a href="#functions">Time and date
+-   functions</a>" above.
++    Library functions described in "<a href="#functions">Time and date
++      functions</a>" above.
+   </li>
+   <li>
+-   The programs <code>tzselect</code>, <code>zdump</code>,
+-   and <code>zic</code>, documented in their man pages.
++    The programs <code>tzselect</code>, <code>zdump</code>,
++    and <code>zic</code>, documented in their man pages.
+   </li>
+   <li>
+-   The format of <code>zic</code> input files, documented in
+-   the <code>zic</code> man page.
++    The format of <code>zic</code> input files, documented in
++    the <code>zic</code> man page.
+   </li>
+   <li>
+-   The format of <code>zic</code> output files, documented in
+-   the <code>tzfile</code> man page.
++    The format of <code>zic</code> output files, documented in
++    the <code>tzfile</code> man page.
+   </li>
+   <li>
+-   The format of zone table files, documented in <code>zone1970.tab</code>.
++    The format of zone table files, documented in <code>zone1970.tab</code>.
+   </li>
+   <li>
+-   The format of the country code file, documented in <code>iso3166.tab</code>.
++    The format of the country code file, documented in <code>iso3166.tab</code>.
+   </li>
+   <li>
+-   The version number of the code and data, as the first line of
+-   the text file '<code>version</code>' in each release.
++    The version number of the code and data, as the first line of
++    the text file '<code>version</code>' in each release.
+   </li>
+ </ul>
++
+ <p>
+ Interface changes in a release attempt to preserve compatibility with
+-recent releases.  For example, tz data files typically do not rely on
+-recently-added <code>zic</code> features, so that users can run
+-older <code>zic</code> versions to process newer data
+-files.  <a href="tz-link.html">Sources for time zone and daylight
+-saving time data</a> describes how
+-releases are tagged and distributed.
++recent releases.
++For example, <code><abbr>tz</abbr></code> data files typically do not
++rely on recently-added <code>zic</code> features, so that users can
++run older <code>zic</code> versions to process newer data files.
++<a href="tz-link.html#download">Downloading
++the <code><abbr>tz</abbr></code> database</a> describes how releases
++are tagged and distributed.
+ </p>
+ 
+ <p>
+-Interfaces not listed above are less stable.  For example, users
+-should not rely on particular UT offsets or abbreviations for
+-timestamps, as data entries are often based on guesswork and these
+-guesses may be corrected or improved.
++Interfaces not listed above are less stable.
++For example, users should not rely on particular <abbr>UT</abbr>
++offsets or abbreviations for timestamps, as data entries are often
++based on guesswork and these guesses may be corrected or improved.
+ </p>
+-  </section>
++</section>
+ 
+-
+-  <section>
+-    <h2 id="calendar">Calendrical issues</h2>
++<section>
++  <h2 id="calendar">Calendrical issues</h2>
+ <p>
+ Calendrical issues are a bit out of scope for a time zone database,
+ but they indicate the sort of problems that we would run into if we
+-extended the time zone database further into the past.  An excellent
+-resource in this area is Nachum Dershowitz and Edward M. Reingold,
+-<cite><a href="https://www.cs.tau.ac.il/~nachum/calendar-book/third-edition/">Calendrical
++extended the time zone database further into the past.
++An excellent resource in this area is Nachum Dershowitz and Edward M.
++Reingold, <cite><a
++href="https://www.cs.tau.ac.il/~nachum/calendar-book/third-edition/">Calendrical
+ Calculations: Third Edition</a></cite>, Cambridge University Press (2008).
+-Other information and sources are given in the file '<samp>calendars</samp>'
+-in the tz distribution.  They sometimes disagree.
++Other information and sources are given in the file '<code>calendars</code>'
++in the <code><abbr>tz</abbr></code> distribution.
++They sometimes disagree.
+ </p>
+-  </section>
++</section>
+ 
+-
+-  <section>
+-    <h2 id="planets">Time and time zones on other planets</h2>
++<section>
++  <h2 id="planets">Time and time zones on other planets</h2>
+ <p>
+-Some people's work schedules use Mars time.  Jet Propulsion Laboratory
+-(JPL) coordinators have kept Mars time on and off at least since 1997
+-for the Mars Pathfinder mission.  Some of their family members have
+-also adapted to Mars time.  Dozens of special Mars watches were built
+-for JPL workers who kept Mars time during the Mars Exploration
+-Rovers mission (2004).  These timepieces look like normal Seikos and
+-Citizens but use Mars seconds rather than terrestrial seconds.
++Some people's work schedules
++use <a href="https://en.wikipedia.org/wiki/Timekeeping on Mars">Mars time</a>.
++Jet Propulsion Laboratory (JPL) coordinators have kept Mars time on
++and off at least since 1997 for the
++<a href="https://en.wikipedia.org/wiki/Mars_Pathfinder#End_of_mission">Mars
++Pathfinder</a> mission.
++Some of their family members have also adapted to Mars time.
++Dozens of special Mars watches were built for JPL workers who kept
++Mars time during the Mars Exploration Rovers mission (2004).
++These timepieces look like normal Seikos and Citizens but use Mars
++seconds rather than terrestrial seconds.
+ </p>
+ 
+ <p>
+ A Mars solar day is called a "sol" and has a mean period equal to
+-about 24 hours 39 minutes 35.244 seconds in terrestrial time.  It is
+-divided into a conventional 24-hour clock, so each Mars second equals
+-about 1.02749125 terrestrial seconds.
++about 24 hours 39 minutes 35.244 seconds in terrestrial time.
++It is divided into a conventional 24-hour clock, so each Mars second
++equals about 1.02749125 terrestrial seconds.
+ </p>
+ 
+ <p>
+-The prime meridian of Mars goes through the center of the crater
+-Airy-0, named in honor of the British astronomer who built the
+-Greenwich telescope that defines Earth's prime meridian.  Mean solar
+-time on the Mars prime meridian is called Mars Coordinated Time (MTC).
++The <a href="https://en.wikipedia.org/wiki/Prime_meridian">prime
++meridian</a> of Mars goes through the center of the crater
++<a href="https://en.wikipedia.org/wiki/Airy-0">Airy-0</a>, named in
++honor of the British astronomer who built the Greenwich telescope that
++defines Earth's prime meridian.
++Mean solar time on the Mars prime meridian is
++called <a href="https://en.wikipedia.org/wiki/Mars_Coordinated_Time">Mars
++Coordinated Time (<abbr>MTC</abbr>)</a>.
+ </p>
+ 
+ <p>
+ Each landed mission on Mars has adopted a different reference for
+ solar time keeping, so there is no real standard for Mars time zones.
+-For example, the Mars Exploration Rover project (2004) defined two
+-time zones "Local Solar Time A" and "Local Solar Time B" for its two
+-missions, each zone designed so that its time equals local true solar
+-time at approximately the middle of the nominal mission.  Such a "time
+-zone" is not particularly suited for any application other than the
+-mission itself.
++For example, the
++<a href="https://en.wikipedia.org/wiki/Mars_Exploration_Rover">Mars
++Exploration Rover</a> project (2004) defined two time zones "Local
++Solar Time A" and "Local Solar Time B" for its two missions, each zone
++designed so that its time equals local true solar time at
++approximately the middle of the nominal mission.
++Such a "time zone" is not particularly suited for any application
++other than the mission itself.
+ </p>
+ 
+ <p>
+ Many calendars have been proposed for Mars, but none have achieved
+-wide acceptance.  Astronomers often use Mars Sol Date (MSD) which is a
++wide acceptance.
++Astronomers often use Mars Sol Date (<abbr>MSD</abbr>) which is a
+ sequential count of Mars solar days elapsed since about 1873-12-29
+-12:00 GMT.
++12:00 <abbr>GMT</abbr>.
+ </p>
+ 
+ <p>
+ In our solar system, Mars is the planet with time and calendar most
+-like Earth's.  On other planets, Sun-based time and calendars would
+-work quite differently.  For example, although Mercury's sidereal
+-rotation period is 58.646 Earth days, Mercury revolves around the Sun
+-so rapidly that an observer on Mercury's equator would see a sunrise
+-only every 175.97 Earth days, i.e., a Mercury year is 0.5 of a Mercury
+-day.  Venus is more complicated, partly because its rotation is
+-slightly retrograde: its year is 1.92 of its days.  Gas giants like
+-Jupiter are trickier still, as their polar and equatorial regions
+-rotate at different rates, so that the length of a day depends on
+-latitude.  This effect is most pronounced on Neptune, where the day is
+-about 12 hours at the poles and 18 hours at the equator.
++like Earth's.
++On other planets, Sun-based time and calendars would work quite
++differently.
++For example, although Mercury's
++<a href="https://en.wikipedia.org/wiki/Rotation_period">sidereal
++rotation period</a> is 58.646 Earth days, Mercury revolves around the
++Sun so rapidly that an observer on Mercury's equator would see a
++sunrise only every 175.97 Earth days, i.e., a Mercury year is 0.5 of a
++Mercury day.
++Venus is more complicated, partly because its rotation is slightly
++<a href="https://en.wikipedia.org/wiki/Retrograde_motion">retrograde</a>:
++its year is 1.92 of its days.
++Gas giants like Jupiter are trickier still, as their polar and
++equatorial regions rotate at different rates, so that the length of a
++day depends on latitude.
++This effect is most pronounced on Neptune, where the day is about 12
++hours at the poles and 18 hours at the equator.
+ </p>
+ 
+ <p>
+-Although the tz database does not support time on other planets, it is
+-documented here in the hopes that support will be added eventually.
++Although the <code><abbr>tz</abbr></code> database does not support
++time on other planets, it is documented here in the hopes that support
++will be added eventually.
+ </p>
+ 
+ <p>
+-Sources:
++Sources for time on other planets:
+ </p>
++
+ <ul>
+   <li>
+-Michael Allison and Robert Schmunk,
+-"<a href="https://www.giss.nasa.gov/tools/mars24/help/notes.html">Technical
+-Notes on Mars Solar Time as Adopted by the Mars24 Sunclock</a>"
+-(2015-06-30).
++    Michael Allison and Robert Schmunk,
++    "<a href="https://www.giss.nasa.gov/tools/mars24/help/notes.html">Technical
++      Notes on Mars Solar Time as Adopted by the Mars24 Sunclock</a>"
++    (2015-06-30).
+   </li>
+   <li>
+-Jia-Rui Chong,
+-"<a href="http://articles.latimes.com/2004/jan/14/science/sci-marstime14">Workdays
+-Fit for a Martian</a>", Los Angeles Times
+-(2004-01-14), pp A1, A20-A21.
++    Jia-Rui Chong,
++    "<a href="http://articles.latimes.com/2004/jan/14/science/sci-marstime14">Workdays
++    Fit for a Martian</a>", <cite>Los Angeles Times</cite>
++    (2004-01-14), pp A1, A20-A21.
+   </li>
+   <li>
+-Tom Chmielewski,
+-"<a href="https://www.theatlantic.com/technology/archive/2015/02/jet-lag-is-worse-on-mars/386033/">Jet
+-Lag Is Worse on Mars</a>", The Atlantic (2015-02-26)
++    Tom Chmielewski,
++    "<a href="https://www.theatlantic.com/technology/archive/2015/02/jet-lag-is-worse-on-mars/386033/">Jet
++    Lag Is Worse on Mars</a>", <cite>The Atlantic</cite> (2015-02-26)
+   </li>
+   <li>
+-Matt Williams,
+-"<a href="https://www.universetoday.com/37481/days-of-the-planets/">How
+-long is a day on the other planets of the solar system?</a>"
+-(2017-04-27).
++    Matt Williams,
++    "<a href="https://www.universetoday.com/37481/days-of-the-planets/">How
++    long is a day on the other planets of the solar system?</a>"
++    (2017-04-27).
+   </li>
+ </ul>
+-  </section>
++</section>
+ 
+-  <footer>
+-    <hr>
+-This file is in the public domain, so clarified as of 2009-05-17 by
+-Arthur David Olson.
+-  </footer>
++<footer>
++  <hr>
++  This file is in the public domain, so clarified as of 2009-05-17 by
++  Arthur David Olson.
++</footer>
+ </body>
+ </html>
+--- contrib/tzdata/version.orig
++++ contrib/tzdata/version
+@@ -1 +1 @@
+-2018c
++2018d
+--- contrib/tzdata/ziguard.awk.orig
++++ contrib/tzdata/ziguard.awk
+@@ -0,0 +1,62 @@
++# Convert tzdata source into vanguard or rearguard form.
++
++# Contributed by Paul Eggert.  This file is in the public domain.
++
++# This is not a general-purpose converter; it is designed for current tzdata.
++#
++# When converting to vanguard form, the output can use negative SAVE
++# values.
++#
++# When converting to rearguard form, the output uses only nonnegative
++# SAVE values.  The idea is for the output data to simulate the behavior
++# of the input data as best it can within the constraints of the
++# rearguard format.
++
++BEGIN {
++  dst_type["vanguard.zi"] = 1
++  dst_type["main.zi"] = 1
++  dst_type["rearguard.zi"] = 1
++
++  # The command line should set OUTFILE to the name of the output file.
++  if (!dst_type[outfile]) exit 1
++  vanguard = outfile == "vanguard.zi"
++}
++
++/^Zone/ { zone = $2 }
++
++outfile != "main.zi" {
++  in_comment = /^#/
++
++  # If this line should differ due to Ireland using negative SAVE values,
++  # uncomment the desired version and comment out the undesired one.
++  Rule_Eire = /^#?Rule[\t ]+Eire[\t ]/
++  Zone_Dublin_post_1968 \
++    = (zone == "Europe/Dublin" && /^#?[\t ]+[01]:00[\t ]/ \
++       && (!$(in_comment + 4) || 1968 < $(in_comment + 4)))
++  if (Rule_Eire || Zone_Dublin_post_1968) {
++    if ((Rule_Eire \
++	 || (Zone_Dublin_post_1968 && $(in_comment + 3) == "IST/GMT"))	\
++	== vanguard) {
++      sub(/^#/, "")
++    } else if (/^[^#]/) {
++      sub(/^/, "#")
++    }
++  }
++}
++
++# If a Link line is followed by a Zone line for the same data, comment
++# out the Link line.  This can happen if backzone overrides a Link
++# with a Zone.
++/^Link/ {
++  linkline[$3] = NR
++}
++/^Zone/ {
++  sub(/^Link/, "#Link", line[linkline[$2]])
++}
++
++{ line[NR] = $0 }
++
++END {
++  for (i = 1; i <= NR; i++)
++    print line[i]
++}
+--- contrib/tzdata/zishrink.awk.orig
++++ contrib/tzdata/zishrink.awk
+@@ -37,7 +37,7 @@
+   # Remove comments, normalize spaces, and append a space to each line.
+   sub(/#.*/, "", line)
+   line = line " "
+-  gsub(/[\f\r\t\v ]+/, " ", line)
++  gsub(/[\t ]+/, " ", line)
+ 
+   # Abbreviate keywords.  Do not abbreviate "Link" to just "L",
+   # as pre-2017c zic erroneously diagnoses "Li" as ambiguous.
+@@ -148,7 +148,7 @@
+   print "# This zic input file is in the public domain."
+ }
+ 
+-/^[\f\r\t\v ]*[^#\f\r\t\v ]/ {
++/^[\t ]*[^#\t ]/ {
+   process_input_line($0)
+ }
+ 
+--- contrib/tzdata/zone.tab.orig
++++ contrib/tzdata/zone.tab
+@@ -429,7 +429,7 @@
+ US	+643004-1652423	America/Nome	Alaska (west)
+ US	+515248-1763929	America/Adak	Aleutian Islands
+ US	+211825-1575130	Pacific/Honolulu	Hawaii
+-UY	-3453-05611	America/Montevideo
++UY	-345433-0561245	America/Montevideo
+ UZ	+3940+06648	Asia/Samarkand	Uzbekistan (west)
+ UZ	+4120+06918	Asia/Tashkent	Uzbekistan (east)
+ VA	+415408+0122711	Europe/Vatican
+--- contrib/tzdata/zone1970.tab.orig
++++ contrib/tzdata/zone1970.tab
+@@ -13,7 +13,7 @@
+ #     See the file '/usr/share/misc/iso3166'.
+ # 2.  Latitude and longitude of the zone's principal location
+ #     in ISO 6709 sign-degrees-minutes-seconds format,
+-#     either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS,
++#     either ±DDMM±DDDMM or ±DDMMSS±DDDMMSS,
+ #     first latitude (+ is north), then longitude (+ is east).
+ # 3.  Zone name used in value of TZ environment variable.
+ #     Please see the theory.html file for how zone names are chosen.
+@@ -372,7 +372,7 @@
+ US	+643004-1652423	America/Nome	Alaska (west)
+ US	+515248-1763929	America/Adak	Aleutian Islands
+ US,UM	+211825-1575130	Pacific/Honolulu	Hawaii
+-UY	-3453-05611	America/Montevideo
++UY	-345433-0561245	America/Montevideo
+ UZ	+3940+06648	Asia/Samarkand	Uzbekistan (west)
+ UZ	+4120+06918	Asia/Tashkent	Uzbekistan (east)
+ VE	+1030-06656	America/Caracas
diff --git a/share/security/patches/EN-18:03/tzdata-2018d.patch.asc b/share/security/patches/EN-18:03/tzdata-2018d.patch.asc
new file mode 100644
index 0000000000..5726647c14
--- /dev/null
+++ b/share/security/patches/EN-18:03/tzdata-2018d.patch.asc
@@ -0,0 +1,18 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQKTBAABCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlrEZxZfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
+MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
+5cIkGg//aNWHcadGK3+kKQlSQJj47Fa+EpYhAyDwlIzJjIS72X5GwehgSNXBQb6j
+KyXlS5U8AmjJ5BgpjOzmoRCOvKaMe6FrasvRicjyKSgXizXNsEtySwS6DJEKbpci
+/sGyU3J4h1StAkIQWZLECH2WjJ8HL/d9/9RBfCnOdG5p2iIkYDGLDIWczZ7bJNwX
+QlBPaL+E3qG8L8HDvfCkm72YIjoVGCAymM8h6MnF/ZYGqhKUD238d7bUVFcQkeoU
+A9+NO/Py4bva890pYFGQQGs67Orh54k1n4KHFTcurVgB4b9Eme5H/TrYOtwfeuVK
+4+mpkLQoNRot+BBdxpJQZuT+R7xFT6w1WTsUJC1D+reJVIm9BFVgnh6nNAcON3mM
+vIeCMPuO9DkXKp42NFR53cOw76h3l6OyC6Xhb8bya/UEZFEFwy6R8mXJHssDrVg2
+KcTmzHEIcFefTpLnlDCIj/glrgT03yIab/6JvclqYedzBxWbz/6QlvFfBjhDLLA6
+ctepdAjvPZjPtD5snvyctTpP8YUIyEfxVT20BXVCFdpFuEjvJHr2QjqSGrRo2gMk
+cWylBK4YOfphwv0IDgZV1N+9tiOcfgAjjS5O9dqd2TNGrGDC23BifHNsBcxhdI50
+NqoBmeMduYfVOiie3lDo0jMHCEXicSR9MVvTrAOMwqw+SueyNYY=
+=+BEu
+-----END PGP SIGNATURE-----
diff --git a/share/security/patches/EN-18:04/mem.10.patch b/share/security/patches/EN-18:04/mem.10.patch
new file mode 100644
index 0000000000..79b312969b
--- /dev/null
+++ b/share/security/patches/EN-18:04/mem.10.patch
@@ -0,0 +1,101 @@
+--- sys/compat/svr4/svr4_misc.c.orig
++++ sys/compat/svr4/svr4_misc.c
+@@ -260,6 +260,7 @@
+ 	u_long *cookies = NULL, *cookiep;
+ 	int ncookies;
+ 
++	memset(&svr4_dirent, 0, sizeof(svr4_dirent));
+ 	DPRINTF(("svr4_sys_getdents64(%d, *, %d)\n",
+ 		uap->fd, uap->nbytes));
+ 	error = getvnode(td->td_proc->p_fd, uap->fd,
+--- sys/dev/drm/drm_bufs.c.orig
++++ sys/dev/drm/drm_bufs.c
+@@ -935,6 +935,7 @@
+ 			if (dma->bufs[i].buf_count) {
+ 				struct drm_buf_desc from;
+ 
++				memset(&from, 0, sizeof(from));
+ 				from.count = dma->bufs[i].buf_count;
+ 				from.size = dma->bufs[i].buf_size;
+ 				from.low_mark = dma->bufs[i].freelist.low_mark;
+--- sys/dev/drm/drm_irq.c.orig
++++ sys/dev/drm/drm_irq.c
+@@ -357,7 +357,7 @@
+ 		goto out;
+ 
+ 	crtc = modeset->crtc;
+-	if (crtc >= dev->num_crtcs) {
++	if (crtc < 0 || crtc >= dev->num_crtcs) {
+ 		ret = EINVAL;
+ 		goto out;
+ 	}
+--- sys/dev/hpt27xx/hpt27xx_osm_bsd.c.orig
++++ sys/dev/hpt27xx/hpt27xx_osm_bsd.c
+@@ -1402,7 +1402,7 @@
+ {
+ 	PHPT_IOCTL_PARAM piop=(PHPT_IOCTL_PARAM)data;
+ 	IOCTL_ARG ioctl_args;
+-	HPT_U32 bytesReturned;
++	HPT_U32 bytesReturned = 0;
+ 
+ 	switch (cmd){
+ 	case HPT_DO_IOCONTROL:
+@@ -1432,7 +1432,7 @@
+ 		}
+ 	
+ 		if (ioctl_args.nOutBufferSize) {
+-			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK);
++			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK | M_ZERO);
+ 			if (!ioctl_args.lpOutBuffer)
+ 				goto invalid;
+ 		}
+--- sys/dev/hptnr/hptnr_osm_bsd.c.orig
++++ sys/dev/hptnr/hptnr_osm_bsd.c
+@@ -1584,7 +1584,7 @@
+ {
+ 	PHPT_IOCTL_PARAM piop=(PHPT_IOCTL_PARAM)data;
+ 	IOCTL_ARG ioctl_args;
+-	HPT_U32 bytesReturned;
++	HPT_U32 bytesReturned = 0;
+ 
+ 	switch (cmd){
+ 	case HPT_DO_IOCONTROL:
+@@ -1614,7 +1614,7 @@
+ 		}
+ 	
+ 		if (ioctl_args.nOutBufferSize) {
+-			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK);
++			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK | M_ZERO);
+ 			if (!ioctl_args.lpOutBuffer)
+ 				goto invalid;
+ 		}
+--- sys/dev/hptrr/hptrr_osm_bsd.c.orig
++++ sys/dev/hptrr/hptrr_osm_bsd.c
+@@ -1231,7 +1231,7 @@
+ {
+ 	PHPT_IOCTL_PARAM piop=(PHPT_IOCTL_PARAM)data;
+ 	IOCTL_ARG ioctl_args;
+-	HPT_U32 bytesReturned;
++	HPT_U32 bytesReturned = 0;
+ 
+ 	switch (cmd){
+ 	case HPT_DO_IOCONTROL:
+@@ -1261,7 +1261,7 @@
+ 		}
+ 	
+ 		if (ioctl_args.nOutBufferSize) {
+-			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK);
++			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK | M_ZERO);
+ 			if (!ioctl_args.lpOutBuffer)
+ 				goto invalid;
+ 		}
+--- sys/i386/ibcs2/ibcs2_misc.c.orig
++++ sys/i386/ibcs2/ibcs2_misc.c
+@@ -352,6 +352,7 @@
+ #define	BSD_DIRENT(cp)		((struct dirent *)(cp))
+ #define	IBCS2_RECLEN(reclen)	(reclen + sizeof(u_short))
+ 
++	memset(&idb, 0, sizeof(idb));
+ 	error = getvnode(td->td_proc->p_fd, uap->fd,
+ 	    cap_rights_init(&rights, CAP_READ), &fp);
+ 	if (error != 0)
diff --git a/share/security/patches/EN-18:04/mem.10.patch.asc b/share/security/patches/EN-18:04/mem.10.patch.asc
new file mode 100644
index 0000000000..2217ae763c
--- /dev/null
+++ b/share/security/patches/EN-18:04/mem.10.patch.asc
@@ -0,0 +1,18 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQKTBAABCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlrEZxtfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
+MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
+5cKXuhAAop4wsNHYzAOlbVm2dzsLYgWFW5VBTR0py0XH1vxh3Q3KN4lcodQQOUrw
+FRS6nkf6CAcrXFdxoOmno2UK612awe44zXc9xIGYU41iJdj83Cj/UKtPRpVC1FTw
+2dxdsLVlGIoZMOijuyTDYsphS9opUezFX6pJxJ6yMxrxeeZW/sJwmYGFI/75KOi+
+pEgd02ukmjdmxY6+y/AfqKau7QyyJkMH87rxmmWXLGlBw398/HFrSzmSewPTQ++U
+ajjG/4Tftz/I7IaDMPe7xduxl2dYJnNfwjdB6S5Zgpo+eAq8wk00vMcf18v4XMYd
+anlha15JOdVORV/agLaqA3wIRCPYwHQdbbQDqSWpqo6h1rv3+lbv/OXbx9e+KJFt
+u0wuxlhbeuNqOia2yIGF/q4ZkgPD7K/meSlbda5xxBW5nBMK7mIjGvPGWLvQv/GA
+NGpYjYXT93Uys269f8qn/9uwfzuBn89h6XUg5xZTlsBfvo7lr1eeIXH1qkCkY3+z
+3RDcTb7qz8cj52nezL78Bi/zu/4iJULnKBMIUWrriHNCpW1Iso5XZ028+vEZDr8P
+HYU3sekQNGHY0HqibM64eeKlGfb2PPwucIWP526hbZFitKqqSqmP1cnODVf/yqGI
+B3Onoh4ACCg2ef7/Az425jFYWVQwAMnuOC9JYlfl+QOMw9uhx/I=
+=CpHQ
+-----END PGP SIGNATURE-----
diff --git a/share/security/patches/EN-18:04/mem.11.patch b/share/security/patches/EN-18:04/mem.11.patch
new file mode 100644
index 0000000000..88a3f75114
--- /dev/null
+++ b/share/security/patches/EN-18:04/mem.11.patch
@@ -0,0 +1,101 @@
+--- sys/compat/svr4/svr4_misc.c.orig
++++ sys/compat/svr4/svr4_misc.c
+@@ -259,6 +259,7 @@
+ 	u_long *cookies = NULL, *cookiep;
+ 	int ncookies;
+ 
++	memset(&svr4_dirent, 0, sizeof(svr4_dirent));
+ 	DPRINTF(("svr4_sys_getdents64(%d, *, %d)\n",
+ 		uap->fd, uap->nbytes));
+ 	error = getvnode(td, uap->fd, cap_rights_init(&rights, CAP_READ), &fp);
+--- sys/dev/drm/drm_bufs.c.orig
++++ sys/dev/drm/drm_bufs.c
+@@ -935,6 +935,7 @@
+ 			if (dma->bufs[i].buf_count) {
+ 				struct drm_buf_desc from;
+ 
++				memset(&from, 0, sizeof(from));
+ 				from.count = dma->bufs[i].buf_count;
+ 				from.size = dma->bufs[i].buf_size;
+ 				from.low_mark = dma->bufs[i].freelist.low_mark;
+--- sys/dev/drm/drm_irq.c.orig
++++ sys/dev/drm/drm_irq.c
+@@ -351,7 +351,7 @@
+ 		goto out;
+ 
+ 	crtc = modeset->crtc;
+-	if (crtc >= dev->num_crtcs) {
++	if (crtc < 0 || crtc >= dev->num_crtcs) {
+ 		ret = EINVAL;
+ 		goto out;
+ 	}
+--- sys/dev/hpt27xx/hpt27xx_osm_bsd.c.orig
++++ sys/dev/hpt27xx/hpt27xx_osm_bsd.c
+@@ -1402,7 +1402,7 @@
+ {
+ 	PHPT_IOCTL_PARAM piop=(PHPT_IOCTL_PARAM)data;
+ 	IOCTL_ARG ioctl_args;
+-	HPT_U32 bytesReturned;
++	HPT_U32 bytesReturned = 0;
+ 
+ 	switch (cmd){
+ 	case HPT_DO_IOCONTROL:
+@@ -1432,7 +1432,7 @@
+ 		}
+ 	
+ 		if (ioctl_args.nOutBufferSize) {
+-			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK);
++			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK | M_ZERO);
+ 			if (!ioctl_args.lpOutBuffer)
+ 				goto invalid;
+ 		}
+--- sys/dev/hptnr/hptnr_osm_bsd.c.orig
++++ sys/dev/hptnr/hptnr_osm_bsd.c
+@@ -1584,7 +1584,7 @@
+ {
+ 	PHPT_IOCTL_PARAM piop=(PHPT_IOCTL_PARAM)data;
+ 	IOCTL_ARG ioctl_args;
+-	HPT_U32 bytesReturned;
++	HPT_U32 bytesReturned = 0;
+ 
+ 	switch (cmd){
+ 	case HPT_DO_IOCONTROL:
+@@ -1614,7 +1614,7 @@
+ 		}
+ 	
+ 		if (ioctl_args.nOutBufferSize) {
+-			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK);
++			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK | M_ZERO);
+ 			if (!ioctl_args.lpOutBuffer)
+ 				goto invalid;
+ 		}
+--- sys/dev/hptrr/hptrr_osm_bsd.c.orig
++++ sys/dev/hptrr/hptrr_osm_bsd.c
+@@ -1231,7 +1231,7 @@
+ {
+ 	PHPT_IOCTL_PARAM piop=(PHPT_IOCTL_PARAM)data;
+ 	IOCTL_ARG ioctl_args;
+-	HPT_U32 bytesReturned;
++	HPT_U32 bytesReturned = 0;
+ 
+ 	switch (cmd){
+ 	case HPT_DO_IOCONTROL:
+@@ -1261,7 +1261,7 @@
+ 		}
+ 	
+ 		if (ioctl_args.nOutBufferSize) {
+-			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK);
++			ioctl_args.lpOutBuffer = malloc(ioctl_args.nOutBufferSize, M_DEVBUF, M_WAITOK | M_ZERO);
+ 			if (!ioctl_args.lpOutBuffer)
+ 				goto invalid;
+ 		}
+--- sys/i386/ibcs2/ibcs2_misc.c.orig
++++ sys/i386/ibcs2/ibcs2_misc.c
+@@ -342,6 +342,7 @@
+ #define	BSD_DIRENT(cp)		((struct dirent *)(cp))
+ #define	IBCS2_RECLEN(reclen)	(reclen + sizeof(u_short))
+ 
++	memset(&idb, 0, sizeof(idb));
+ 	error = getvnode(td, uap->fd, cap_rights_init(&rights, CAP_READ), &fp);
+ 	if (error != 0)
+ 		return (error);
diff --git a/share/security/patches/EN-18:04/mem.11.patch.asc b/share/security/patches/EN-18:04/mem.11.patch.asc
new file mode 100644
index 0000000000..795896185d
--- /dev/null
+++ b/share/security/patches/EN-18:04/mem.11.patch.asc
@@ -0,0 +1,18 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQKTBAABCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlrEZx9fFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
+MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
+5cK3zQ//YG/fDMHFV8wgvb5WPnDjyHFQS5XYKMP5XPOyjhtNhz07oIpejPsPOhsK
+/iy4zlgRwDbOnibwYh04gaq/IghzF/i1ncaZ+C9YDpA1eVYXsdj7UUQFJl1qQLar
+Qpogx77tPB5nxqGuKSBe7jvm85riTuwJktRnGRKhumCcqPvzhuu4vvsTwOmo1tN9
+2fEiHJ1UVhK03XFd4avSULv8CL7165Y6PflcEfeq0sf7Wn9UTi3F4S93DnM2lf9z
+0WQXpqBM/qJa8XkYb4GFX143dZgNJhonyAreAYksNh2/EXFQnP46LnudxeWShkOM
+dtbqIbIEFBF0aRT9TDmmTZdZP9palqI7Wh7OzLCJ1XWdo/hNzRJor1moB7RG8D2y
+ac0uhUcShsaPHJbEFFDZvJYS9ajd8anklyHcwKZk+pLiimX66Z4MGiBEVAtTTn/c
+tEOgJf3Fpo76Rzg9DJ/+D0VClPp4evKMqztmWW5y1BBOVQIGD/W5rOAFMGxV9ocw
+bQFerxi6tUZeT7D5iN84VVfWQwEP75YBbXXOvp324RjmQ2S70aSlLTdjOtSdR66j
+rGFZGLU+yhCi4o4Au+G/lpEBuyymfVvd7ohqw5lEtv+t250vVWjF7eWN9eIrbgvl
+nx8LDmc4AdK9cWG0NJMRjuXk7qI6PTodljKj+HP4/zhhzSv/a1A=
+=19FX
+-----END PGP SIGNATURE-----
diff --git a/share/security/patches/SA-18:04/vt.patch b/share/security/patches/SA-18:04/vt.patch
new file mode 100644
index 0000000000..3113b1f123
--- /dev/null
+++ b/share/security/patches/SA-18:04/vt.patch
@@ -0,0 +1,20 @@
+--- sys/dev/vt/vt_font.c.orig
++++ sys/dev/vt/vt_font.c
+@@ -42,6 +42,7 @@
+ 
+ /* Some limits to prevent abnormal fonts from being loaded. */
+ #define	VTFONT_MAXMAPPINGS	65536
++#define	VTFONT_MAXGLYPHS	131072
+ #define	VTFONT_MAXGLYPHSIZE	2097152
+ #define	VTFONT_MAXDIMENSION	128
+ 
+@@ -171,7 +172,8 @@
+ 	/* Make sure the dimensions are valid. */
+ 	if (f->width < 1 || f->height < 1)
+ 		return (EINVAL);
+-	if (f->width > VTFONT_MAXDIMENSION || f->height > VTFONT_MAXDIMENSION)
++	if (f->width > VTFONT_MAXDIMENSION || f->height > VTFONT_MAXDIMENSION ||
++	    f->glyph_count > VTFONT_MAXGLYPHS)
+ 		return (E2BIG);
+ 
+ 	/* Not too many mappings. */
diff --git a/share/security/patches/SA-18:04/vt.patch.asc b/share/security/patches/SA-18:04/vt.patch.asc
new file mode 100644
index 0000000000..40049f17a8
--- /dev/null
+++ b/share/security/patches/SA-18:04/vt.patch.asc
@@ -0,0 +1,18 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQKTBAABCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlrEZwJfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
+MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
+5cLTbhAAosjOICeBsoemI83sQhRCBfDUrSo1ZiJWAutTzLOGJzK3MwAb4t1WRp1c
+KCVi933s44srnJQQgLz1Md7g80kt3n+/dg7WfyXsBNPY2bEkznD6x6TDoP3gHwBe
+xITDg9MPjzD50Tzc3Eh0j4GS6kTKpex6BlnvXRd8VkMgyLAbPIBjD6NlZuzNgU7G
+hOlAQmOkzVe5ltm2GhPlkKZNQG/0NVOaoM0Vg2MdVTHrSEIQ0vwO3+kKOhE/sciM
+EauG4/jd01ZE5funXpiQZkevUEKDEkxzxW+G1GtmW+P5qBVJmZrEBTQpDrFOavqY
+CDaHaViBPGluiLSJcuqx7Ml9pmgsl97RSxL5k3OpxPhOPcTTU1bH4q/xOd0g3Fli
+SUjeahiaFniniGM3o/ibAP2mm6R6/fRyQy6q56MuNWwbJ+nsxgRPzEB4qx4/AmV6
+szQ3QY0kSZGnMF3TUvrQroS2kkTVXJOKbFYWfe/wRmpftkzzPVyplgAMfH9E3t3/
+noB30N0PYsT4m++cmw2hRYUvLlfCwCq5wo56t6bxskSawdDFMqWrw4nnucqm9cei
+UFQPuun16kdod49+rOGmHNsJur6t7vmoIybwB9F1RDUs2c9wGm+NJeliCfFLKPJM
+9sSooJQZBKW3uxkhPLf3UP1M/ToAIWiQ95vwVwnm0aeul+aoF3o=
+=KLuI
+-----END PGP SIGNATURE-----
diff --git a/share/security/patches/SA-18:05/ipsec.patch b/share/security/patches/SA-18:05/ipsec.patch
new file mode 100644
index 0000000000..0cd477ca06
--- /dev/null
+++ b/share/security/patches/SA-18:05/ipsec.patch
@@ -0,0 +1,131 @@
+--- sys/netipsec/xform_ah.c.orig
++++ sys/netipsec/xform_ah.c
+@@ -264,7 +264,7 @@
+ #ifdef INET6
+ 	struct ip6_ext *ip6e;
+ 	struct ip6_hdr ip6;
+-	int alloc, len, ad;
++	int ad, alloc, nxt, noff;
+ #endif /* INET6 */
+ 
+ 	switch (proto) {
+@@ -293,7 +293,7 @@
+ 		else
+ 			ip->ip_off = htons(0);
+ 
+-		ptr = mtod(m, unsigned char *) + sizeof(struct ip);
++		ptr = mtod(m, unsigned char *);
+ 
+ 		/* IPv4 option processing */
+ 		for (off = sizeof(struct ip); off < skip;) {
+@@ -374,7 +374,7 @@
+ 
+ 				/* Zeroize all other options. */
+ 				count = ptr[off + 1];
+-				bcopy(ipseczeroes, ptr, count);
++				bcopy(ipseczeroes, ptr + off, count);
+ 				off += count;
+ 				break;
+ 			}
+@@ -447,61 +447,44 @@
+ 		} else
+ 			break;
+ 
+-		off = ip6.ip6_nxt & 0xff; /* Next header type. */
++		nxt = ip6.ip6_nxt & 0xff; /* Next header type. */
+ 
+-		for (len = 0; len < skip - sizeof(struct ip6_hdr);)
+-			switch (off) {
++		for (off = 0; off < skip - sizeof(struct ip6_hdr);)
++			switch (nxt) {
+ 			case IPPROTO_HOPOPTS:
+ 			case IPPROTO_DSTOPTS:
+-				ip6e = (struct ip6_ext *) (ptr + len);
++				ip6e = (struct ip6_ext *)(ptr + off);
++				noff = off + ((ip6e->ip6e_len + 1) << 3);
+ 
++				/* Sanity check. */
++				if (noff > skip - sizeof(struct ip6_hdr))
++					goto error6;
++
+ 				/*
+-				 * Process the mutable/immutable
+-				 * options -- borrows heavily from the
+-				 * KAME code.
++				 * Zero out mutable options.
+ 				 */
+-				for (count = len + sizeof(struct ip6_ext);
+-				     count < len + ((ip6e->ip6e_len + 1) << 3);) {
++				for (count = off + sizeof(struct ip6_ext);
++				     count < noff;) {
+ 					if (ptr[count] == IP6OPT_PAD1) {
+ 						count++;
+ 						continue; /* Skip padding. */
+ 					}
+ 
+-					/* Sanity check. */
+-					if (count > len +
+-					    ((ip6e->ip6e_len + 1) << 3)) {
+-						m_freem(m);
++					ad = ptr[count + 1] + 2;
++					if (count + ad > noff)
++						goto error6;
+ 
+-						/* Free, if we allocated. */
+-						if (alloc)
+-							free(ptr, M_XDATA);
+-						return EINVAL;
+-					}
+-
+-					ad = ptr[count + 1];
+-
+-					/* If mutable option, zeroize. */
+ 					if (ptr[count] & IP6OPT_MUTABLE)
+-						bcopy(ipseczeroes, ptr + count,
+-						    ptr[count + 1]);
+-
++						memset(ptr + count, 0, ad);
+ 					count += ad;
++				}
+ 
+-					/* Sanity check. */
+-					if (count >
+-					    skip - sizeof(struct ip6_hdr)) {
+-						m_freem(m);
++				if (count != noff)
++					goto error6;
+ 
+-						/* Free, if we allocated. */
+-						if (alloc)
+-							free(ptr, M_XDATA);
+-						return EINVAL;
+-					}
+-				}
+-
+ 				/* Advance. */
+-				len += ((ip6e->ip6e_len + 1) << 3);
+-				off = ip6e->ip6e_nxt;
++				off += ((ip6e->ip6e_len + 1) << 3);
++				nxt = ip6e->ip6e_nxt;
+ 				break;
+ 
+ 			case IPPROTO_ROUTING:
+@@ -509,14 +492,15 @@
+ 				 * Always include routing headers in
+ 				 * computation.
+ 				 */
+-				ip6e = (struct ip6_ext *) (ptr + len);
+-				len += ((ip6e->ip6e_len + 1) << 3);
+-				off = ip6e->ip6e_nxt;
++				ip6e = (struct ip6_ext *) (ptr + off);
++				off += ((ip6e->ip6e_len + 1) << 3);
++				nxt = ip6e->ip6e_nxt;
+ 				break;
+ 
+ 			default:
+ 				DPRINTF(("%s: unexpected IPv6 header type %d",
+ 					__func__, off));
++error6:
+ 				if (alloc)
+ 					free(ptr, M_XDATA);
+ 				m_freem(m);
diff --git a/share/security/patches/SA-18:05/ipsec.patch.asc b/share/security/patches/SA-18:05/ipsec.patch.asc
new file mode 100644
index 0000000000..5909e06e9e
--- /dev/null
+++ b/share/security/patches/SA-18:05/ipsec.patch.asc
@@ -0,0 +1,18 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQKTBAABCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlrEZwtfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
+MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
+5cID5xAAm2xSJis9o05EyTAPgoTCjAPHyUg7HFuJB72kdrlmzSaCYrQ294nyhlr2
+K020pNYmKV2s/f3Id1rdVTg6T1XT3FlWPOUiwyuWB1R7YVzagQsB3E5U/ozAlVkm
++iV49G0e4T9wqw1xHql2J0yUl7Nv07YLza6Hu3T+ZsGsqyZi5bmJ8or3gS1C/JaU
+U0MPWPqHsWghEgfVIOrBllSy/GJnLs8ag6/i7IWvmRE2mQXOq6WdtMFSZO4zcDRK
+y88+hpqL8WX1Wn1NOlT7a14gVcrkRSPXzu0rQEXWwal7WfAPzU1MZvWss29PKgiS
+xLqeZPqM8yuZS0wu+Iy9t5iBbRahdYiR7jGWYt+ALG0JxO5vVHddMKtWGMsnefzE
+aywvgnGjB4kKGbzc40iHyf97cvC+bgsfO95CO6n4NBpGCkrZ8oh16UBt2If8dw3R
+I2ygi+fP9AZ4LcjWpt5f2v/m3HbGdWUWgiHxXqiD1GLsbm0kPuKPUhJKUMYoJFdl
+pIjjSsxziWoQ9YvnkPOqW3cXWvrG674WbRd/prG4juLckXP7iXZ+VVx/uqXkFi0K
+Aij/+2asvnFKnoHI1IqhXVK27Z6m2XLLcBtmARmAoXTTxlkUAQvYrFX5w/KKIhd4
+a2VdJGj6HMpGkQuEyoBs6g7mtdV5q7OuYkrdQz78IuJpvA2JUFE=
+=Idvp
+-----END PGP SIGNATURE-----
author	Gordon Tetlow <gordon@FreeBSD.org>	2018-04-04 05:55:14 +0000
committer	Gordon Tetlow <gordon@FreeBSD.org>	2018-04-04 05:55:14 +0000
commit	866286679f1bffc2426cee5e9350f7596dc297d9 (patch)
tree	2db9ce4a7407a6cf02f45ec66dc5db541da68f6c /share
parent	009a15ab0b8b2f059e1adc8c99d4663d624c2600 (diff)