contrib/tzdata: import tzdata 2022a

Merge commit '971fa603f2bdf16273135a00ff16c5585520c53f'

Changes: https://github.com/eggert/tz/blob/2022a/NEWS

MFC after:	3 days

contrib/tzdata/CONTRIBUTING

@@ -1,53 +1,58 @@
-Contributing to the tz code and data
+# Contributing to the tz code and data
+
+Please do not create issues or pull requests on GitHub, as the
+proper procedure for proposing and distributing patches is via
+email as described below.
 
 The time zone database is by no means authoritative: governments
 change timekeeping rules erratically and sometimes with little
 warning, the data entries do not cover all of civil time before
 1970, and undoubtedly errors remain in the code and data.  Feel
 free to fill gaps or fix mistakes, and please email improvements
-to tz@iana.org for use in the future.  In your email, please give
+to <tz@iana.org> for use in the future.  In your email, please give
 reliable sources that reviewers can check.
 
------
+## Contributing technical changes
-
-Developers can contribute technical changes to the source code and
-data as follows.
 
 To email small changes, please run a POSIX shell command like
 'diff -u old/europe new/europe >myfix.patch', and attach
-myfix.patch to the email.
+'myfix.patch' to the email.
 
 For more-elaborate or possibly-controversial changes,
 such as renaming, adding or removing zones, please read
-<https://www.iana.org/time-zones/repository/theory.html> or the file
+"Theory and pragmatics of the tz code and data"
-theory.html.  It is also good to browse the mailing list archives
+<https://www.iana.org/time-zones/repository/theory.html>.
+It is also good to browse the mailing list archives
 <https://mm.icann.org/pipermail/tz/> for examples of patches that tend
 to work well.  Additions to data should contain commentary citing
-reliable sources as justification.  Citations should use https: URLs
+reliable sources as justification.  Citations should use "https:" URLs
 if available.
 
 For changes that fix sensitive security-related bugs, please see the
-file SECURITY.
+distribution's 'SECURITY' file.
 
-Please submit changes against either the latest release in
+Please submit changes against either the latest release
 <https://www.iana.org/time-zones> or the main branch of the development
-repository.  The latter is preferred.  If you use Git the following
+repository.  The latter is preferred.
-workflow may be helpful:
+
+## Sample Git workflow for developing contributions
+
+If you use Git the following workflow may be helpful:
 
   * Copy the development repository.
 
-      git clone https://github.com/eggert/tz.git
+        git clone https://github.com/eggert/tz.git
-      cd tz
+        cd tz
 
   * Get current with the main branch.
 
-      git checkout main
+        git checkout main
-      git pull
+        git pull
 
   * Switch to a new branch for the changes.  Choose a different
     branch name for each change set.
 
-      git checkout -b mybranch
+        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
@@ -60,36 +65,33 @@ workflow may be helpful:
 
   * Debug the changes, e.g.:
 
-      make check
+        make check
-      make install
+        make install
-      ./zdump -v America/Los_Angeles
+        ./zdump -v America/Los_Angeles
 
   * For each separable change, commit it in the new branch, e.g.:
 
-      git add northamerica
+        git add northamerica
-      git commit
+        git commit
 
     See recent 'git log' output for the commit-message style.
 
-  * Create patch files 0001-*, 0002-*, ...
+  * Create patch files 0001-..., 0002-..., ...
 
-      git format-patch main
+        git format-patch main
 
-  * After reviewing the patch files, send the patches to tz@iana.org
+  * After reviewing the patch files, send the patches to <tz@iana.org>
     for others to review.
 
-      git send-email main
+        git send-email main
 
     For an archived example of such an email, see
+    "[PROPOSED] Fix off-by-1 error for Jamaica and T&C before 1913"
     <https://mm.icann.org/pipermail/tz/2018-February/026122.html>.
 
   * Start anew by getting current with the main branch again
     (the second step above).
 
-Please do not create issues or pull requests on GitHub, as the
-proper procedure for proposing and distributing patches is via
-email as illustrated above.
-
 -----
 
 This file is in the public domain.

contrib/tzdata/Makefile

@@ -399,9 +399,10 @@ ZFLAGS=
 ZIC_INSTALL=	$(ZIC) -d '$(DESTDIR)$(TZDIR)' $(LEAPSECONDS)
 
 # The name of a Posix-compliant 'awk' on your system.
-# Older 'mawk' versions, such as the 'mawk' in Ubuntu 16.04, might dump core;
+# mawk 1.3.3 and Solaris 10 /usr/bin/awk do not work.
-# on Ubuntu you can work around this with
+# Also, it is better (though not essential) if 'awk' supports UTF-8,
-#	AWK=		gawk
+# and unfortunately mawk and busybox awk do not support UTF-8.
+# Try AWK=gawk or AWK=nawk if your awk has the abovementioned problems.
 AWK=		awk
 
 # The full path name of a Posix-compliant shell, preferably one that supports
@@ -466,7 +467,9 @@ OK_LINE=	'^'$(OK_CHAR)'*$$'
 
 # Flags to give 'tar' when making a distribution.
 # Try to use flags appropriate for GNU tar.
-GNUTARFLAGS= --numeric-owner --owner=0 --group=0 --mode=go+u,go-w --sort=name
+GNUTARFLAGS= --format=pax --pax-option='delete=atime,delete=ctime' \
+  --numeric-owner --owner=0 --group=0 \
+  --mode=go+u,go-w --sort=name
 TARFLAGS=	`if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \
 		 then echo $(GNUTARFLAGS); \
 		 else :; \
@@ -742,7 +745,7 @@ date:		$(DATEOBJS)
 tzselect:	tzselect.ksh version
 		VERSION=`cat version` && sed \
 			-e 's|#!/bin/bash|#!$(KSHELL)|g' \
-			-e 's|AWK=[^}]*|AWK=$(AWK)|g' \
+			-e 's|AWK=[^}]*|AWK='\''$(AWK)'\''|g' \
 			-e 's|\(PKGVERSION\)=.*|\1='\''($(PACKAGE)) '\''|' \
 			-e 's|\(REPORT_BUGS_TO\)=.*|\1=$(BUGEMAIL)|' \
 			-e 's|TZDIR=[^}]*|TZDIR=$(TZDIR)|' \

contrib/tzdata/NEWS

@@ -1,5 +1,65 @@
 News for the tz database
 
+Release 2022a - 2022-03-15 23:02:01 -0700
+
+  Briefly:
+    Palestine will spring forward on 2022-03-27, not -03-26.
+    zdump -v now outputs better failure indications.
+    Bug fixes for code that reads corrupted TZif data.
+
+  Changes to future timestamps
+
+    Palestine will spring forward on 2022-03-27, not 2022-03-26.
+    (Thanks to Heba Hamad.)  Predict future transitions for first
+    Sunday >= March 25.  Additionally, predict fallbacks to be the first
+    Friday on or after October 23, not October's last Friday, to be more
+    consistent with recent practice.  The first differing fallback
+    prediction is on 2025-10-24, not 2025-10-31.
+
+  Changes to past timestamps
+
+    From 1992 through spring 1996, Ukraine's DST transitions were at
+    02:00 standard time, not at 01:00 UTC.  (Thanks to Alois Treindl.)
+
+    Chile's Santiago Mean Time and its LMT precursor have been adjusted
+    eastward by 1 second to align with past and present law.
+
+  Changes to commentary
+
+    Add several references for Chile's 1946/1947 transitions, some of
+    which only affected portions of the country.
+
+  Changes to code
+
+    Fix bug when mktime gets confused by truncated TZif files with
+    unspecified local time.  (Problem reported by Almaz Mingaleev.)
+
+    Fix bug when 32-bit time_t code reads malformed 64-bit TZif data.
+    (Problem reported by Christos Zoulas.)
+
+    When reading a version 2 or later TZif file, the TZif reader now
+    validates the version 1 header and data block only enough to skip
+    over them, as recommended by RFC 8536 section 4.  Also, the TZif
+    reader no longer mistakenly attempts to parse a version 1 TZIf
+    file header as a TZ string.
+
+    zdump -v now outputs "(localtime failed)" and "(gmtime failed)"
+    when local time and UT cannot be determined for a timestamp.
+
+  Changes to build procedure
+
+    Distribution tarballs now use standard POSIX.1-1988 ustar format
+    instead of GNU format.  Although the formats are almost identical
+    for these tarballs, ustar headers' magic fields contain "ustar"
+    instead of "ustar ", and their version fields contain "00" instead
+    of " ".  The two formats are planned to diverge more significantly
+    for tzdb releases after 2242-03-16 12:56:31 UTC, when the ustar
+    format becomes obsolete and the tarballs switch to pax format, an
+    extension of ustar.  For details about these formats, please see
+    "pax - portable archive interchange", IEEE Std 1003.1-2017,
+    <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13>.
+
+
 Release 2021e - 2021-10-21 18:41:00 -0700
 
   Changes to future timestamps

contrib/tzdata/africa

@@ -918,6 +918,10 @@ Zone Indian/Mauritius	3:50:00 -	LMT	1907 # Port Louis
 #         (car (cdr (cdr a))) (calendar-month-name (car a) t) (car (cdr a))
 #         (car (cdr (cdr b))) (calendar-month-name (car b) t) (car (cdr b)))))
 #     (setq islamic-year (+ 1 islamic-year))))
+#
+# From Milamber (2021-03-31, 2022-03-10), confirming these predictions:
+# https://www.mmsp.gov.ma/fr/actualites.aspx?id=2076
+# https://www.ecoactu.ma/horaires-administration-ramadan-gmtheure-gmt-a-partir-de-dimanche-27-mars/
 
 # Rule	NAME	FROM	TO	-	IN	ON	AT	SAVE	LETTER/S
 Rule	Morocco	1939	only	-	Sep	12	 0:00	1:00	-

contrib/tzdata/asia

@@ -3406,8 +3406,12 @@ Zone	Asia/Karachi	4:28:12 -	LMT	1907
 # ... winter time will begin in Palestine from Friday 10-29, 01:00 AM
 # by 60 minutes backwards.
 #
-# From Paul Eggert (2021-10-20):
+# From Tim Parenti (2021-10-25), per Paul Eggert (2021-10-24):
-# Guess future fall transitions on October's last Friday at 01:00.
+# Guess future fall transitions at 01:00 on the Friday preceding October's
+# last Sunday (i.e., Fri>=23), as this is more consistent with recent practice.
+
+# From Heba Hamad (2022-03-10):
+# summer time will begin in Palestine from Sunday 03-27-2022, 00:00 AM.
 
 # Rule	NAME	FROM	TO	-	IN	ON	AT	SAVE	LETTER/S
 Rule EgyptAsia	1957	only	-	May	10	0:00	1:00	S
@@ -3443,9 +3447,10 @@ Rule Palestine	2016	2018	-	Mar	Sat>=24	1:00	1:00	S
 Rule Palestine	2016	2018	-	Oct	Sat>=24	1:00	0	-
 Rule Palestine	2019	only	-	Mar	29	0:00	1:00	S
 Rule Palestine	2019	only	-	Oct	Sat>=24	0:00	0	-
-Rule Palestine	2020	max	-	Mar	Sat>=24	0:00	1:00	S
+Rule Palestine	2020	2021	-	Mar	Sat>=24	0:00	1:00	S
 Rule Palestine	2020	only	-	Oct	24	1:00	0	-
-Rule Palestine	2021	max	-	Oct	lastFri	1:00	0	-
+Rule Palestine	2021	max	-	Oct	Fri>=23	1:00	0	-
+Rule Palestine	2022	max	-	Mar	Sun>=25	0:00	1:00	S
 
 # Zone	NAME		STDOFF	RULES	FORMAT	[UNTIL]
 Zone	Asia/Gaza	2:17:52	-	LMT	1900 Oct

contrib/tzdata/backzone

@@ -290,6 +290,7 @@ Rule	SL	1932	only	-	Dec	 1	 0:00	0:20	-0040
 Rule	SL	1933	1938	-	Mar	31	24:00	0	-01
 Rule	SL	1933	1939	-	Aug	31	24:00	0:20	-0040
 Rule	SL	1939	only	-	May	31	24:00	0	-01
+
 Zone	Africa/Freetown	-0:53:00 -	LMT	1882
 			-0:53:00 -	FMT	1913 Jul  1 # Freetown MT
 			-1:00	SL	%s	1939 Sep  5
@@ -345,7 +346,15 @@ Zone	Africa/Luanda	0:52:56	-	LMT	1892
 			1:00	-	WAT
 
 # Democratic Republic of the Congo (east)
-Zone Africa/Lubumbashi	1:49:52 -	LMT	1897 Nov 9
+#
+# From Alois Treindl (2022-02-28):
+# My main source for its time zone history is
+# Henri le Corre, Régimes horaires pour l'Europe et l'Afrique.
+# Shanks follows le Corre.  As does Françoise Schneider-Gauquelin in her book
+# Problèmes de l'heure résolus pour le monde entier.
+#
+Zone Africa/Lubumbashi	1:49:52 -	LMT	1897 Nov  9
+			1:00	-	WAT	1920 Apr 25
 			2:00	-	CAT
 
 # Zambia
@@ -752,7 +761,6 @@ Zone America/Port_of_Spain -4:06:04 -	LMT	1912 Mar 2
 			-4:00	-	AST
 Link America/Port_of_Spain America/Marigot
 Link America/Port_of_Spain America/St_Barthelemy
-Link America/Port_of_Spain America/Virgin
 
 # Argentina
 # This entry was intended for the following areas, but has been superseded by
@@ -815,11 +823,11 @@ Link Antarctica/McMurdo Antarctica/South_Pole
 # Syowa station, which is the first antarctic station of Japan,
 # was established on 1957-01-29.  Since Syowa station is still the main
 # station of Japan, it's appropriate for the principal location.
-Zone Antarctica/Syowa	0	-	-00	1957 Jan 29
-			3:00	-	+03
 # See:
 # NIPR Antarctic Research Activities (1999-08-17)
 # http://www.nipr.ac.jp/english/ara01.html
+Zone Antarctica/Syowa	0	-	-00	1957 Jan 29
+			3:00	-	+03
 
 # Yemen
 # Milne says 2:59:54 was the meridian of the saluting battery at Aden,

contrib/tzdata/europe

@@ -2785,8 +2785,26 @@ Zone Europe/Kaliningrad	 1:22:00 -	LMT	1893 Apr
 # says he remembers that Samara opted out of the 1992-01-19 exception
 # 2 days before the switch.
 #
+# From Alois Treindl (2022-02-15):
+# the Russian wikipedia page
+# https://ru.wikipedia.org/wiki/Московское_время#Перемещение_границы_применения_московского_времени_на_восток
+# contains the sentence (in Google translation) "In the autumn of
+# 1981, Arkhangelsk, Vologda, Yaroslavl, Ivanovo, Vladimir, Ryazan,
+# Lipetsk, Voronezh, Rostov-on-Don, Krasnodar and regions to the east
+# of those named (about 30 in total) parted ways with Moscow time.
+# However, the convenience of common time with Moscow turned out to be
+# decisive - in 1982, these regions again switched to Moscow time."
+# Shanks International atlas has similar information, and also the
+# Russian book Zaitsev A., Kutalev D. A new astrologer's reference
+# book. Coordinates of cities and time corrections, - The World of
+# Urania, 2012 (Russian: Зайцев А., Куталёв Д., Новый справочник
+# астролога. Координаты городов и временные поправки).
+# To me it seems that an extra zone is needed, which starts with LMT
+# util 1919, later follows Moscow since 1930, but deviates from it
+# between 1 October 1981 until 1 April 1982.
 #
-# From Paul Eggert (2016-03-18):
+#
+# From Paul Eggert (2022-02-15):
 # Given the above, we appear to be missing some Zone entries for the
 # chaotic early 1980s in Russia.  It's not clear what these entries
 # should be.  For now, sweep this under the rug and just document the
@@ -2833,7 +2851,7 @@ Zone Europe/Simferopol	 2:16:24 -	LMT	1880
 			 1:00	C-Eur	CE%sT	1944 Apr 13
 			 3:00	Russia	MSK/MSD	1990
 			 3:00	-	MSK	1990 Jul  1  2:00
-			 2:00	-	EET	1992
+			 2:00	-	EET	1992 Mar 20
 # Central Crimea used Moscow time 1994/1997.
 #
 # From Paul Eggert (2006-03-22):
@@ -2843,7 +2861,7 @@ Zone Europe/Simferopol	 2:16:24 -	LMT	1880
 # sometime between the 1994 DST switches.  Shanks & Pottenger simply say
 # 1994-09-25 03:00, but that can't be right.  For now, guess it
 # changed in May.
-			 2:00	E-Eur	EE%sT	1994 May
+			 2:00	C-Eur	EE%sT	1994 May
 # From IATA SSIM (1994/1997), which also says that Kerch is still like Kiev.
 			 3:00	E-Eur	MSK/MSD	1996 Mar 31  0:00s
 			 3:00	1:00	MSD	1996 Oct 27  3:00s
@@ -4010,6 +4028,27 @@ Link	Europe/Istanbul	Asia/Istanbul	# Istanbul is in both continents.
 
 # Ukraine
 #
+# From Alois Triendl (2014-03-01):
+# REGULATION A N O V A on March 20, 1992 N 139 ...  means that from
+# 1992 on, Ukraine had DST with begin time at 02:00 am, on last Sunday
+# in March, and end time 03:00 am, last Sunday in September....
+# CABINET OF MINISTERS OF UKRAINE RESOLUTION on May 13, 1996 N 509
+# "On the order of computation time on the territory of Ukraine" ....
+# As this cabinet decision is from May 1996, it seems likely that the
+# transition in March 1996, which predates it, was still at 2:00 am
+# and not at 3:00 as would have been under EU rules.
+# This is why I have set the change to EU rules into May 1996,
+# so that the change in March is stil covered by the Ukraine rule.
+# The next change in October 1996 happened under EU rules....
+# TZ database holds three other zones for Ukraine.... I have not yet
+# worked out the consequences for these three zones, as we (me and my
+# US colleague David Cochrane) are still trying to get more
+# information upon these local deviations from Kiev rules.
+#
+# From Paul Eggert (2022-02-08):
+# For now, assume that Ukraine's other three zones followed the same rules,
+# except that Crimea switched to Moscow time in 1994 as described elsewhere.
+
 # From Igor Karpov, who works for the Ukrainian Ministry of Justice,
 # via Garrett Wollman (2003-01-27):
 # BTW, I've found the official document on this matter. It's government
@@ -4099,7 +4138,7 @@ Zone Europe/Kiev	2:02:04 -	LMT	1880
 			1:00	C-Eur	CE%sT	1943 Nov  6
 			3:00	Russia	MSK/MSD	1990 Jul  1  2:00
 			2:00	1:00	EEST	1991 Sep 29  3:00
-			2:00	E-Eur	EE%sT	1995
+			2:00	C-Eur	EE%sT	1996 May 13
 			2:00	EU	EE%sT
 # Transcarpathia used CET 1990/1991.
 # "Uzhhorod" is the transliteration of the Rusyn/Ukrainian pronunciation, but
@@ -4112,8 +4151,8 @@ Zone Europe/Uzhgorod	1:29:12 -	LMT	1890 Oct
 			3:00	Russia	MSK/MSD	1990
 			3:00	-	MSK	1990 Jul  1  2:00
 			1:00	-	CET	1991 Mar 31  3:00
-			2:00	-	EET	1992
+			2:00	-	EET	1992 Mar 20
-			2:00	E-Eur	EE%sT	1995
+			2:00	C-Eur	EE%sT	1996 May 13
 			2:00	EU	EE%sT
 # Zaporozh'ye and eastern Lugansk oblasts observed DST 1990/1991.
 # "Zaporizhia" is the transliteration of the Ukrainian name, but
@@ -4126,7 +4165,8 @@ Zone Europe/Zaporozhye	2:20:40 -	LMT	1880
 			3:00	-	MSK	1941 Aug 25
 			1:00	C-Eur	CE%sT	1943 Oct 25
 			3:00	Russia	MSK/MSD	1991 Mar 31  2:00
-			2:00	E-Eur	EE%sT	1995
+			2:00	E-Eur	EE%sT	1992 Mar 20
+			2:00	C-Eur	EE%sT	1996 May 13
 			2:00	EU	EE%sT
 
 # Vatican City

contrib/tzdata/leap-seconds.list

@@ -204,10 +204,10 @@
 #	current -- the update time stamp, the data and the name of the file
 #	will not change.
 #
-#	Updated through IERS Bulletin C62
+#	Updated through IERS Bulletin C63
-#	File expires on:  28 June 2022
+#	File expires on:  28 December 2022
 #
-#@	3865363200
+#@	3881174400
 #
 2272060800	10	# 1 Jan 1972
 2287785600	11	# 1 Jul 1972
@@ -252,4 +252,4 @@
 #	the hash line is also ignored in the
 #	computation.
 #
-#h 	599d45bf accd4b4f 8b60e46 49b623 7d13b825
+#h 	732b2044 5863a938 b7e43179 1339c710 ded63837

contrib/tzdata/leapseconds

@@ -72,11 +72,11 @@ Leap	2016	Dec	31	23:59:60	+	S
 # Any additional leap seconds will come after this.
 # This Expires line is commented out for now,
 # so that pre-2020a zic implementations do not reject this file.
-#Expires 2022	Jun	28	00:00:00
+#Expires 2022	Dec	28	00:00:00
 
 # POSIX timestamps for the data in this file:
 #updated 1467936000 (2016-07-08 00:00:00 UTC)
-#expires 1656374400 (2022-06-28 00:00:00 UTC)
+#expires 1672185600 (2022-12-28 00:00:00 UTC)
 
-#	Updated through IERS Bulletin C62
+#	Updated through IERS Bulletin C63
-#	File expires on:  28 June 2022
+#	File expires on:  28 December 2022

contrib/tzdata/southamerica

@@ -1086,7 +1086,7 @@ Zone America/Rio_Branco	-4:31:12 -	LMT	1914
 
 # Chile
 
-# From Paul Eggert (2015-04-03):
+# From Paul Eggert (2022-03-15):
 # Shanks & Pottenger says America/Santiago introduced standard time in
 # 1890 and rounds its UT offset to 70W40; guess that in practice this
 # was the same offset as in 1916-1919.  It also says Pacific/Easter
@@ -1109,7 +1109,7 @@ Zone America/Rio_Branco	-4:31:12 -	LMT	1914
 # Historia de la hora oficial de Chile (retrieved 2012-10-24).  See:
 # https://web.archive.org/web/20121024234627/http://www.horaoficial.cl/horaof.htm
 # A fancier Spanish version (requiring mouse-clicking) is at:
-# http://www.horaoficial.cl/historia_hora.html
+# http://www.horaoficial.cl/historia_hora.php
 # Conflicts between [1] and [2] were resolved as follows:
 #
 #  - [1] says the 1910 transition was Jan 1, [2] says Jan 10 and cites
@@ -1118,7 +1118,8 @@ Zone America/Rio_Branco	-4:31:12 -	LMT	1914
 #  - [1] says SMT was -4:42:45, [2] says Chile's official time from
 #    1916 to 1919 was -4:42:46.3, the meridian of Chile's National
 #    Astronomical Observatory (OAN), then located in what is now
-#    Quinta Normal in Santiago.  Go with [2], rounding it to -4:42:46.
+#    Quinta Normal in Santiago.  Go with [1], as this matches the meridian
+#    referred to by the relevant Chilean laws to this day.
 #
 #  - [1] says the 1918 transition was Sep 1, [2] says Sep 10 and cites
 #    Boletín No. 22, Aviso No. 129/1918 (1918-08-23).  Go with [2].
@@ -1140,6 +1141,32 @@ Zone America/Rio_Branco	-4:31:12 -	LMT	1914
 # this is known to work for DST transitions starting in 2008 and
 # may well be true for earlier transitions.
 
+# From Tim Parenti (2022-03-15):
+# For a brief period of roughly six weeks in 1946, DST was only observed on an
+# emergency basis in specific regions of central Chile; namely, "the national
+# territory between the provinces of Coquimbo and Concepción, inclusive".
+# This was enacted by Decree 3,891, dated 1946-07-13, and took effect
+# 1946-07-14 24:00, advancing these central regions to -03.
+# https://www.diariooficial.interior.gob.cl/versiones-anteriores/do-h/19460715/#page/1
+# The decree contemplated "[t]hat this advancement of the Official Time, even
+# though it has been proposed for the cities of Santiago and Valparaíso only,
+# must be agreed with that of other cities, due to the connection of various
+# activities that require it, such as, for example, the operation of rail
+# services".  It was originally set to expire after 30 days but was extended
+# through 1946-08-31 by Decree 4,506, dated 1946-08-13.
+# https://www.diariooficial.interior.gob.cl/versiones-anteriores/do-h/19460814/#page/1
+#
+# Law Number 8,522, promulgated 1946-08-27, reunified Chilean clocks at their
+# new "Summer Time" of -04, reckoned as that of "the meridian of the
+# Astronomical Observatory of Lo Espejo, advanced by 42 minutes and 45
+# seconds".
+# https://www.diariooficial.interior.gob.cl/versiones-anteriores/do-h/19460828/#page/1
+# After a brief "Winter Time" stint at -05 beginning 1947-04-01, Law Number
+# 8,777, promulgated 1947-05-17, established year-round -04 "from 23:00 on the
+# second day after it is published in the 'Diario Oficial'."  It was published
+# on Monday 1947-05-19 and so took effect from Wednesday 1947-05-21 23:00.
+# https://www.diariooficial.interior.gob.cl/versiones-anteriores/do-h/19470519/#page/1
+
 # From Eduardo Krell (1995-10-19):
 # The law says to switch to DST at midnight [24:00] on the second SATURDAY
 # of October....  The law is the same for March and October.
@@ -1298,12 +1325,12 @@ Rule	Chile	2019	max	-	Sep	Sun>=2	4:00u	1:00	-
 # IATA SSIM anomalies: (1992-02) says 1992-03-14;
 # (1996-09) says 1998-03-08.  Ignore these.
 # Zone	NAME		STDOFF	RULES	FORMAT	[UNTIL]
-Zone America/Santiago	-4:42:46 -	LMT	1890
+Zone America/Santiago	-4:42:45 -	LMT	1890
-			-4:42:46 -	SMT	1910 Jan 10 # Santiago Mean Time
+			-4:42:45 -	SMT	1910 Jan 10 # Santiago Mean Time
 			-5:00	-	-05	1916 Jul  1
-			-4:42:46 -	SMT	1918 Sep 10
+			-4:42:45 -	SMT	1918 Sep 10
 			-4:00	-	-04	1919 Jul  1
-			-4:42:46 -	SMT	1927 Sep  1
+			-4:42:45 -	SMT	1927 Sep  1
 			-5:00	Chile	-05/-04	1932 Sep  1
 			-4:00	-	-04	1942 Jun  1
 			-5:00	-	-05	1942 Aug  1
@@ -1313,11 +1340,11 @@ Zone America/Santiago	-4:42:46 -	LMT	1890
 			-5:00	-	-05	1947 May 21 23:00
 			-4:00	Chile	-04/-03
 Zone America/Punta_Arenas -4:43:40 -	LMT	1890
-			-4:42:46 -	SMT	1910 Jan 10
+			-4:42:45 -	SMT	1910 Jan 10
 			-5:00	-	-05	1916 Jul  1
-			-4:42:46 -	SMT	1918 Sep 10
+			-4:42:45 -	SMT	1918 Sep 10
 			-4:00	-	-04	1919 Jul  1
-			-4:42:46 -	SMT	1927 Sep  1
+			-4:42:45 -	SMT	1927 Sep  1
 			-5:00	Chile	-05/-04	1932 Sep  1
 			-4:00	-	-04	1942 Jun  1
 			-5:00	-	-05	1942 Aug  1

contrib/tzdata/theory.html

@@ -296,7 +296,7 @@ in decreasing order of importance:
   </li>
   <li>
     If a name is changed, put its old spelling in the
-    '<code>backward</code>' file.
+    '<code>backward</code>' file as a link to the new spelling.
     This means old spellings will continue to work.
     Ordinarily a name change should occur only in the rare case when
     a location's consensus English-language spelling changes; for example,
@@ -348,22 +348,37 @@ timestamps correctly and it increased maintenance burden.
 </ul>
 
 <p>
-The file '<code>zone1970.tab</code>' lists geographical locations used
+The file <code>zone1970.tab</code> lists geographical locations used
 to name timezones.
 It is intended to be an exhaustive list of names for geographic
 regions as described above; this is a subset of the timezones in the data.
-Although a '<code>zone1970.tab</code>' location's
+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.
+The backward-compatibility file <code>zone.tab</code> is similar
+but conforms to the older-version guidelines related to <abbr>ISO</abbr> 3166-1;
+it lists only one country code per entry and unlike <code>zone1970.tab</code>
+it can list names defined in <code>backward</code>.
 </p>
 
 <p>
-Excluding '<code>backward</code>' should not affect the other data.
+The database defines each timezone name to be a zone, or a link to a zone.
-If '<code>backward</code>' is excluded, excluding
+The source file <code>backward</code> defines links for backward
-'<code>etcetera</code>' should not affect the remaining data.
+compatibility; it does not define zones.
+Although <code>backward</code> was originally designed to be optional,
+nowadays distributions typically use it
+and no great weight should be attached to whether a link
+is defined in <code>backward</code> or in some other file.
+The source file <code>etcetera</code> defines names that may be useful
+on platforms that do not support POSIX-style <code>TZ</code> strings;
+no other source file other than <code>backward</code>
+contains links to its zones.
+One of <code>etcetera</code>'s names is <code>GMT</code>,
+used by functions like <code>gmtime</code> to obtain leap
+second information on platforms that support leap seconds.
 </p>
 </section>
 

contrib/tzdata/version

@@ -1 +1 @@
-2021e
+2022a

contrib/tzdata/ziguard.awk

@@ -104,13 +104,19 @@ DATAFORM != "main" {
   }
   if (!vanguard && $1 == "Rule" && $2 == "Morocco" && 2019 <= $3) {
     if ($9 == "0") {
+      last_std_date = $3 " " $6 " " $7 "  " $8
       sub(/\t0\t/, "\t1:00\t")
     } else {
       sub(/\t-1:00\t/, "\t0\t")
     }
   }
   if (!vanguard && $1 == "1:00" && $2 == "Morocco" && $3 == "+01/+00") {
-    sub(/1:00\tMorocco\t\+01\/\+00$/, "0:00\tMorocco\t+00/+01")
+    # This introduces a transition from 01:59:59 +00 to 03:00:00 +01
+    # with both times being standard (i.e., a change to standard UT offset).
+    # This is rearguard's way to approximate the actual prediction,
+    # which is that of an ordinary transition from DST to standard time.
+    sub(/1:00\tMorocco\t\+01\/\+00$/,
+	"0:00\tMorocco\t+00/+01\t" last_std_date "\n\t\t\t 1:00\t-\t+01")
   }
 }