summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat
-rw-r--r--contrib/tzdata/CONTRIBUTING12
-rw-r--r--contrib/tzdata/Makefile123
-rw-r--r--contrib/tzdata/NEWS145
-rw-r--r--contrib/tzdata/africa57
-rw-r--r--contrib/tzdata/antarctica3
-rw-r--r--contrib/tzdata/asia177
-rw-r--r--contrib/tzdata/australasia114
-rw-r--r--contrib/tzdata/backzone48
-rw-r--r--contrib/tzdata/checktab.awk9
-rw-r--r--contrib/tzdata/europe84
-rw-r--r--contrib/tzdata/northamerica27
-rw-r--r--contrib/tzdata/southamerica430
-rw-r--r--contrib/tzdata/theory.html1793
-rw-r--r--contrib/tzdata/version2
-rw-r--r--contrib/tzdata/ziguard.awk62
-rw-r--r--contrib/tzdata/zishrink.awk4
-rw-r--r--contrib/tzdata/zone.tab2
-rw-r--r--contrib/tzdata/zone1970.tab4
18 files changed, 1889 insertions, 1207 deletions
diff --git a/contrib/tzdata/CONTRIBUTING b/contrib/tzdata/CONTRIBUTING
index 716f32b..0cfc77f 100644
--- a/contrib/tzdata/CONTRIBUTING
+++ b/contrib/tzdata/CONTRIBUTING
@@ -25,7 +25,8 @@ justification. Citations should use https: URLs if available.
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 @@ repository. If you use Git the following workflow may be helpful:
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 @@ repository. If you use Git the following workflow may be helpful:
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).
diff --git a/contrib/tzdata/Makefile b/contrib/tzdata/Makefile
index 4f448d2..c69e01b 100644
--- a/contrib/tzdata/Makefile
+++ b/contrib/tzdata/Makefile
@@ -10,6 +10,15 @@ VERSION= unknown
# 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 @@ LOCALTIME= GMT
# 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,13 +198,18 @@ LDLIBS=
# -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>
# -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_CHARSET3= 'abcdefghijklmnopqrstuvwxyz{|}~'
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 @@ TDATA= $(YDATA) $(NDATA) $(BACKWARD)
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 @@ VERSION_DEPS= \
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 @@ version: $(VERSION_DEPS)
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 @@ posix_packrat:
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 @@ check_character_set: $(ENCHILADA)
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 @@ check_sorted: backward backzone iso3166.tab zone.tab zone1970.tab
$(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_tzs: $(TZS) $(TZS_NEW)
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 @@ clean_misc:
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 @@ tarballs traditional_tarballs signatures traditional_signatures: version
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 @@ zic.o: private.h tzfile.h version.h
.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)
diff --git a/contrib/tzdata/NEWS b/contrib/tzdata/NEWS
index 2bd0aa8..8afe3a4 100644
--- a/contrib/tzdata/NEWS
+++ b/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 @@ Release 2018c - 2018-01-22 23:00:44 -0800
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 @@ Release 2016b - 2016-03-12 17:30:14 -0800
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.)
diff --git a/contrib/tzdata/africa b/contrib/tzdata/africa
index 02115ad..2f7217a 100644
--- a/contrib/tzdata/africa
+++ b/contrib/tzdata/africa
@@ -115,13 +115,13 @@ Zone Africa/Algiers 0:12:12 - LMT 1891 Mar 15 0:01
# 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 @@ Zone Africa/Cairo 2:05:09 - LMT 1900 Oct
# See Africa/Abidjan.
# Ghana
-# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
+
+# From Paul Eggert (2018-01-30):
# 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
+# 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
+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 @@ Zone Africa/Accra -0:00:52 - LMT 1918
# 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 @@ Zone Africa/Tripoli 0:52:44 - LMT 1920
# 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 @@ Zone Indian/Reunion 3:41:52 - LMT 1911 Jun # Saint-Denis
# 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 @@ Zone Indian/Reunion 3:41:52 - LMT 1911 Jun # Saint-Denis
# 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
diff --git a/contrib/tzdata/antarctica b/contrib/tzdata/antarctica
index d9c132a..866cf4f 100644
--- a/contrib/tzdata/antarctica
+++ b/contrib/tzdata/antarctica
@@ -75,7 +75,8 @@ Zone Antarctica/Casey 0 - -00 1969
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
diff --git a/contrib/tzdata/asia b/contrib/tzdata/asia
index 3f6e95c..998a7d4 100644
--- a/contrib/tzdata/asia
+++ b/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 @@ Zone Asia/Kabul 4:36:48 - LMT 1890
# (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 @@ Zone Asia/Yerevan 2:58:00 - LMT 1924 May 2
# 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 @@ Zone Asia/Baku 3:19:24 - LMT 1924 May 2
# 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 1974 1977 - Oct Sun>=15 3:30 0 S
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,61 +1107,61 @@ Zone Asia/Jayapura 9:22:48 - LMT 1932 Nov
# 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
# 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 @@ Zone Asia/Tehran 3:25:44 - LMT 1916
# 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 @@ Rule Japan 1950 1951 - May Sat>=1 24:00 1:00 D
# 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 @@ Rule Japan 1950 1951 - May Sat>=1 24:00 1:00 D
# 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 @@ Zone Asia/Oral 3:25:24 - LMT 1924 May 2 # or Ural'sk
# 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 @@ Zone Asia/Beirut 2:22:00 - LMT 1880
# 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 @@ Zone Indian/Maldives 4:54:00 - LMT 1880 # Malé
# 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 @@ Rule Mongol 1983 only - Oct 1 0:00 0 -
# 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 @@ Zone Asia/Karachi 4:28:12 - LMT 1907
# [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 @@ Zone Asia/Karachi 4:28:12 - LMT 1907
# 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 2012 only - Sep 21 1:00 0 -
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 @@ Zone Asia/Hebron 2:20:23 - LMT 1900 Oct
# 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 @@ Zone Asia/Tashkent 4:37:11 - LMT 1924 May 2
# 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.
diff --git a/contrib/tzdata/australasia b/contrib/tzdata/australasia
index b4ef168..32ad61e 100644
--- a/contrib/tzdata/australasia
+++ b/contrib/tzdata/australasia
@@ -196,20 +196,20 @@ Zone Australia/Broken_Hill 9:25:48 - LMT 1895 Feb
# 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 @@ Zone Indian/Cocos 6:27:40 - LMT 1900
# 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 @@ Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki
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 @@ Zone Pacific/Nauru 11:07:40 - LMT 1921 Jan 15 # Uaobe
# 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 1929 1933 - Mar Sun>=15 2:00 0 M
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 @@ Link Pacific/Auckland Antarctica/McMurdo
# 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 @@ Link Pacific/Pago_Pago Pacific/Midway # in US minor outlying islands
# 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 @@ Zone Pacific/Fakaofo -11:24:56 - LMT 1901
# 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 @@ Zone Pacific/Wake 11:06:28 - LMT 1901
# 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 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901
# 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 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901
# "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 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901
# 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 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901
# 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
diff --git a/contrib/tzdata/backzone b/contrib/tzdata/backzone
index 3006b27..d1fd83b 100644
--- a/contrib/tzdata/backzone
+++ b/contrib/tzdata/backzone
@@ -170,13 +170,13 @@ Zone Africa/Lome 0:04:52 - LMT 1893
# 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 @@ Zone America/Aruba -4:40:24 - LMT 1912 Feb 12 # Oranjestad
# 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/Montreal -4:54:16 - LMT 1884
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 @@ Zone Asia/Bahrain 3:22:20 - LMT 1920 # Manamah
# 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 @@ Zone Europe/Belfast -0:23:40 - LMT 1880 Aug 2
# 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 @@ Zone Europe/Isle_of_Man -0:17:55 - LMT 1883 Mar 30 0:00s
# 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
diff --git a/contrib/tzdata/checktab.awk b/contrib/tzdata/checktab.awk
index 2397673..393ab19 100644
--- a/contrib/tzdata/checktab.awk
+++ b/contrib/tzdata/checktab.awk
@@ -126,6 +126,7 @@ $1 ~ /^#/ { next }
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 @@ $1 ~ /^#/ { next }
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 @@ END {
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", \
diff --git a/contrib/tzdata/europe b/contrib/tzdata/europe
index 6c1ccbe..3f092a4 100644
--- a/contrib/tzdata/europe
+++ b/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/Jersey
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 @@ Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2
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 @@ Zone Europe/Budapest 1:16:20 - LMT 1890 Oct
# 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 @@ Zone Europe/Warsaw 1:24:00 - LMT 1880
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 @@ Rule Port 1983 only - Mar lastSun 2:00s 1:00 S
#
# 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 @@ Zone Europe/Lisbon -0:36:45 - LMT 1884
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 @@ Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada
-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 @@ Zone Europe/Kaliningrad 1:22:00 - LMT 1893 Apr
# 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 @@ Zone Atlantic/Canary -1:01:36 - LMT 1922 Mar # Las Palmas de Gran C.
# 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 @@ Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1
# 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):
diff --git a/contrib/tzdata/northamerica b/contrib/tzdata/northamerica
index a014126..06db1a8 100644
--- a/contrib/tzdata/northamerica
+++ b/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 @@ Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21
# ...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 @@ Zone America/Denver -6:59:56 - LMT 1883 Nov 18 12:00:04
# 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 @@ Zone America/Indiana/Vevay -5:40:16 - LMT 1883 Nov 18 12:19:44
-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 @@ Zone America/Tegucigalpa -5:48:52 - LMT 1921 Apr
# 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 America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre
#
# 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
diff --git a/contrib/tzdata/southamerica b/contrib/tzdata/southamerica
index 2049177..9784044 100644
--- a/contrib/tzdata/southamerica
+++ b/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 @@ Rule Arg 1988 only - Dec 1 0:00 1:00 S
# 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 @@ Rule Arg 1989 1992 - Oct Sun>=15 0:00 1:00 S
# 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 @@ Rule Arg 2000 only - Mar 3 0:00 0 -
# 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 @@ Rule Arg 2008 only - Oct Sun>=15 0:00 1:00 S
# 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 @@ Rule Arg 2008 only - Oct Sun>=15 0:00 1:00 S
# 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 @@ Rule Arg 2008 only - Oct Sun>=15 0:00 1:00 S
# 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 @@ Zone America/Argentina/Mendoza -4:35:16 - LMT 1894 Oct 31
# 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 @@ Zone America/La_Paz -4:32:36 - LMT 1890
# 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 @@ Rule Brazil 1953 only - Mar 1 0:00 0 -
# 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 @@ Rule Brazil 1993 only - Jan 31 0:00 0 -
# 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 @@ Rule Brazil 1997 only - Feb 16 0:00 0 -
# 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,34 +880,34 @@ Rule Brazil 2000 only - Feb 27 0:00 0 -
# 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
# [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 @@ Rule Brazil 2016 2022 - Feb Sun>=15 0:00 0 -
# ... 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 @@ Zone America/Rio_Branco -4:31:12 - LMT 1914
# 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 2008 only - Mar 30 3:00u 0 -
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 @@ Zone Antarctica/Palmer 0 - -00 1965
# "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 @@ Link America/Curacao America/Kralendijk # Caribbean Netherlands
# 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 @@ Zone Pacific/Galapagos -5:58:24 - LMT 1931 # Puerto Baquerizo Moreno
# 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 @@ Zone America/Guyana -3:52:40 - LMT 1915 Mar # Georgetown
# 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 @@ Rule Para 1996 only - Mar 1 0:00 0 -
# 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 @@ Rule Para 1998 2001 - Mar Sun>=1 0:00 0 -
# 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 @@ Rule Para 2002 2003 - Sep Sun>=1 0:00 1:00 S
# 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 @@ Rule Para 2005 2009 - Mar Sun>=8 0:00 0 -
# 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 @@ Zone America/Asuncion -3:50:40 - LMT 1890
# 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 @@ Link America/Port_of_Spain America/Tortola # Virgin Islands (UK)
# 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 @@ Rule Uruguay 2006 only - Mar 12 2:00 0 -
# 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
diff --git a/contrib/tzdata/theory.html b/contrib/tzdata/theory.html
index ff85f53..4d8726d 100644
--- a/contrib/tzdata/theory.html
+++ b/contrib/tzdata/theory.html
@@ -1,26 +1,20 @@
-<!DOCTYPE html>
<html lang="en">
<head>
<title>Theory and pragmatics of the tz code and data</title>
<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 @@ necessarily follow database guidelines.
</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,843 +280,1008 @@ and these older names are still supported.
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.
-
- 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.
- </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 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.
-<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>
+ 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'.
-<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 (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>
+ <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>A few abbreviations also follow the pattern that
-GMT/BST established for time in the UK. They are:
+ <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>
-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.
</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.
- </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.
- </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.
- </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.
- </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.
- </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.
- </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.
- </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.
- </li>
- <li>
- Changes that are modeled as instantaneous transitions in the tz
- 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.
- </li>
- <li>
- Early timekeeping practices, even assuming perfect clocks, were
- often not specified to the accuracy that the tz 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.
- </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.
- </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.
- </li>
- <li>
- 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.
- </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>.
- </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.
- </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 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 <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.
+ </li>
+ <li>
+ 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 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 <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 <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 <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
+ <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.
+ </li>
+ <li>
+ 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 <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
+ <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 <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.
+ </li>
+ <li>
+ 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
+ <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, <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 <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.
-</p>
- </section>
-
- <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.
+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>
+ <h2 id="functions">Time and date functions</h2>
<p>
-POSIX has the following properties and limitations.
+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>
+
+<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>
+ <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>
- 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:
+ </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>
+
+ <pre><code>TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'</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>
- 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='Pacific/Auckland'</code></pre>
+ </li>
+ <li>
+ 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 <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
+ <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 <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.
+ </li>
+ <li>
+ 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>
- <pre><code>TZ='Pacific/Auckland'</code></pre>
+<h3 id="POSIX-extensions">Extensions to POSIX in the
+<code><abbr>tz</abbr></code> code</h3>
+<ul>
+ <li>
+ <p>
+ 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 <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>
- 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.
+ 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 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 supports platforms with a time zone abbreviation member in
+ <code>struct tm</code>, e.g., <code>tm_zone</code>.
</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.)
+ 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>
- 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.
+ 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>
- POSIX requires that systems ignore leap seconds.
+ Negative <code>time_t</code> values are supported, on systems
+ where <code>time_t</code> is signed.
</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.
+ These functions can account for leap seconds, thanks to Bradley White.
</li>
</ul>
+
+<h3 id="vestigial">POSIX features no longer needed</h3>
<p>
-These are the extensions that have been made to the POSIX functions:
+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>
- <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.
- </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).
- </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>
+ 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 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 <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>
-<p>
-Points of interest to folks with other systems:
-</p>
+
+<h3 id="other-portability">Other portability notes</h3>
<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>.
- </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.
- </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.
- </li>
- <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>
diff --git a/contrib/tzdata/version b/contrib/tzdata/version
index f6a71fe..ae3ff7c 100644
--- a/contrib/tzdata/version
+++ b/contrib/tzdata/version
@@ -1 +1 @@
-2018c
+2018d
diff --git a/contrib/tzdata/ziguard.awk b/contrib/tzdata/ziguard.awk
new file mode 100644
index 0000000..6da3691
--- /dev/null
+++ b/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]
+}
diff --git a/contrib/tzdata/zishrink.awk b/contrib/tzdata/zishrink.awk
index 23d623e..d617644 100644
--- a/contrib/tzdata/zishrink.awk
+++ b/contrib/tzdata/zishrink.awk
@@ -37,7 +37,7 @@ function process_input_line(line, field, end, i, n, startdef)
# 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 @@ BEGIN {
print "# This zic input file is in the public domain."
}
-/^[\f\r\t\v ]*[^#\f\r\t\v ]/ {
+/^[\t ]*[^#\t ]/ {
process_input_line($0)
}
diff --git a/contrib/tzdata/zone.tab b/contrib/tzdata/zone.tab
index e1bfdee..f92c919 100644
--- a/contrib/tzdata/zone.tab
+++ b/contrib/tzdata/zone.tab
@@ -429,7 +429,7 @@ US +593249-1394338 America/Yakutat Alaska - Yakutat
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
diff --git a/contrib/tzdata/zone1970.tab b/contrib/tzdata/zone1970.tab
index 7c4793a..64273f6 100644
--- a/contrib/tzdata/zone1970.tab
+++ b/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 +593249-1394338 America/Yakutat Alaska - Yakutat
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
OpenPOWER on IntegriCloud