path: root/website/static/security/patches/EN-18:03/tzdata-2018d.patch

--- 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