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.
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.
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).
# 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
+# Alternatively, if you discover you've got the wrong time zone, you can just
# zic -l rightzone
# to correct things.
# Use the command
# 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.)
-# Alternately, if you discover you've got the wrong time zone, you can just
+# daylight saving time.
+# Alternatively, if you discover you've got the wrong time zone, you can just
# zic -p rightzone
# to correct things.
# Use the command
# -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.
$(GCC_INSTRUMENT) \
-Wall -Wextra \
-Walloc-size-larger-than=100000 -Warray-bounds=2 \
- -Wbad-function-cast -Wcast-align -Wdate-time \
+ -Wbad-function-cast -Wcast-align=strict -Wdate-time \
-Wdeclaration-after-statement -Wdouble-promotion \
-Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation \
-Winit-self -Wjump-misses-init -Wlogical-op \
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs \
-Wold-style-definition -Woverlength-strings -Wpointer-arith \
- -Wshadow -Wshift-overflow=2 -Wstrict-prototypes -Wstringop-overflow=5 \
+ -Wshadow -Wshift-overflow=2 -Wstrict-prototypes -Wstringop-overflow=4 \
+ -Wstringop-truncation -Wsuggest-attribute=cold \
-Wsuggest-attribute=const -Wsuggest-attribute=format \
+ -Wsuggest-attribute=malloc \
-Wsuggest-attribute=noreturn -Wsuggest-attribute=pure \
-Wtrampolines -Wundef -Wuninitialized -Wunused \
-Wvariadic-macros -Wvla -Wwrite-strings \
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 '#';
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
tzfile.5 tzfile.h tzselect.8 tzselect.ksh \
workman.sh yearistype.sh \
zdump.8 zdump.c zic.8 zic.c \
+ ziguard.awk zishrink.awk \
zone.tab zone1970.tab zoneinfo2tdf.pl
# And for the benefit of csh users on systems that assume the user
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)
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 DATAFORM=`expr $@ : '\(.*\).zi'` -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
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
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); \
$(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
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
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'
done
rm -fr time_t.dir
+TRADITIONAL_ASC = \
+ tzcode$(VERSION).tar.gz.asc \
+ tzdata$(VERSION).tar.gz.asc
+ALL_ASC = $(TRADITIONAL_ASC) \
+ tzdata$(VERSION)-rearguard.tar.gz.asc \
+ tzdb-$(VERSION).tar.lz.asc
+
tarballs traditional_tarballs signatures traditional_signatures: version
VERSION=`cat version` && \
$(MAKE) VERSION="$$VERSION" $@_version
-tarballs_version: traditional_tarballs_version tzdb-$(VERSION).tar.lz
+# 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 \
+ tzdata$(VERSION)-rearguard.tar.gz \
+ tzdb-$(VERSION).tar.lz
traditional_tarballs_version: \
tzcode$(VERSION).tar.gz tzdata$(VERSION).tar.gz
-signatures_version: traditional_signatures_version tzdb-$(VERSION).tar.lz.asc
-traditional_signatures_version: \
- tzcode$(VERSION).tar.gz.asc tzdata$(VERSION).tar.gz.asc \
+signatures_version: $(ALL_ASC)
+traditional_signatures_version: $(TRADITIONAL_ASC)
tzcode$(VERSION).tar.gz: set-timestamps.out
LC_ALL=C && export LC_ALL && \
gzip $(GZIPFLAGS) >$@.out
mv $@.out $@
+tzdata$(VERSION)-rearguard.tar.gz: rearguard.zi set-timestamps.out
+ rm -fr tzdata$(VERSION)-rearguard.dir
+ mkdir tzdata$(VERSION)-rearguard.dir
+ ln $(COMMON) $(DATA) $(MISC) tzdata$(VERSION)-rearguard.dir
+ cd tzdata$(VERSION)-rearguard.dir && \
+ rm -f $(TDATA) $(PACKRATDATA) version
+ for f in $(TDATA) $(PACKRATDATA); do \
+ rearf=tzdata$(VERSION)-rearguard.dir/$$f; \
+ $(AWK) -v DATAFORM=rearguard -f ziguard.awk $$f >$$rearf && \
+ touch -cmr `ls -t ziguard.awk $$f` $$rearf || exit; \
+ done
+ sed '1s/$$/-rearguard/' \
+ <version >tzdata$(VERSION)-rearguard.dir/version
+ touch -cmr version tzdata$(VERSION)-rearguard.dir/version
+ LC_ALL=C && export LC_ALL && \
+ (cd tzdata$(VERSION)-rearguard.dir && \
+ tar $(TARFLAGS) -cf - $(COMMON) $(DATA) $(MISC) | \
+ gzip $(GZIPFLAGS)) >$@.out
+ mv $@.out $@
+
tzdb-$(VERSION).tar.lz: set-timestamps.out
rm -fr tzdb-$(VERSION)
mkdir tzdb-$(VERSION)
mv $@.out $@
tzcode$(VERSION).tar.gz.asc: tzcode$(VERSION).tar.gz
- gpg --armor --detach-sign $?
-
tzdata$(VERSION).tar.gz.asc: tzdata$(VERSION).tar.gz
- gpg --armor --detach-sign $?
-
+tzdata$(VERSION)-rearguard.tar.gz.asc: tzdata$(VERSION)-rearguard.tar.gz
tzdb-$(VERSION).tar.lz.asc: tzdb-$(VERSION).tar.lz
+$(ALL_ASC):
gpg --armor --detach-sign $?
typecheck:
.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)
News for the tz database
+Release 2018e - 2018-05-01 23:42:51 -0700
+
+ Briefly:
+
+ North Korea switches back to +09 on 2018-05-05.
+ The main format uses negative DST again, for Ireland etc.
+ 'make tarballs' now also builds a rearguard tarball.
+ New 's' and 'd' suffixes in SAVE columns of Rule and Zone lines.
+
+ Changes to past and future time stamps
+
+ North Korea switches back from +0830 to +09 on 2018-05-05.
+ (Thanks to Kang Seonghoon, Arthur David Olson, Seo Sanghyeon,
+ and Tim Parenti.)
+
+ Bring back the negative-DST changes of 2018a, except be more
+ compatible with data parsers that do not support negative DST.
+ Also, this now affects historical time stamps in Namibia and the
+ former Czechoslovakia, not just Ireland. The main format now uses
+ negative DST to model time stamps in Europe/Dublin (from 1971 on),
+ Europe/Prague (1946/7), and Africa/Windhoek (1994/2017). This
+ does not affect UT offsets, only time zone abbreviations and the
+ tm_isdst flag. Also, this does not affect rearguard or vanguard
+ formats; effectively the main format now uses vanguard instead of
+ rearguard format. Data parsers that do not support negative DST
+ can still use data from the rearguard tarball described below.
+
+ Changes to build procedure
+
+ The command 'make tarballs' now also builds the tarball
+ tzdataVERSION-rearguard.tar.gz, which is like tzdataVERSION.tar.gz
+ except that it uses rearguard format intended for trailing-edge
+ data parsers.
+
+ Changes to data format and to code
+
+ The SAVE column of Rule and Zone lines can now have an 's' or 'd'
+ suffix, which specifies whether the adjusted time is standard time
+ or daylight saving time. If no suffix is given, daylight saving
+ time is used if and only if the SAVE column is nonzero; this is
+ the longstanding behavior. Although this new feature is not used
+ in tzdata, it could be used to specify the legal time in Namibia
+ 1994-2017, as opposed to the popular time (see below).
+
+ Changes to past time stamps
+
+ From 1994 through 2017 Namibia observed DST in winter, not summer.
+ That is, it used negative DST, as Ireland still does. This change
+ does not affect UTC offsets; it affects only the tm_isdst flag and
+ the abbreviation used during summer, which is now CAT, not WAST.
+ Although (as noted by Michael Deckers) summer and winter time were
+ both simply called "standard time" in Namibian law, in common
+ practice winter time was considered to be DST (as noted by Stephen
+ Colebourne). The full effect of this change is only in vanguard
+ format; in rearguard and main format, the tm_isdst flag is still
+ zero in winter and nonzero in summer.
+
+ In 1946/7 Czechoslovakia also observed negative DST in winter.
+ The full effect of this change is only in vanguard format; in
+ rearguard and main formats, it is modeled as plain GMT without
+ daylight saving. Also, the dates of some 1944/5 DST transitions
+ in Czechoslovakia have been changed.
+
+
+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 Portugal 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
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
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.)
# tz@iana.org for general use in the future). For more, please see
# the file CONTRIBUTING in the tz distribution.
-# From Paul Eggert (2017-02-20):
+# From Paul Eggert (2017-04-09):
#
# Unless otherwise specified, the source for data through 1990 is:
# Thomas G. Shanks and Rique Pottenger, The International Atlas (6th edition),
# cannot now come up with solid citations.
#
# I invented the following abbreviations; corrections are welcome!
-# +02 WAST West Africa Summer Time
+# +02 WAST West Africa Summer Time (no longer used)
# +03 CAST Central Africa Summer Time (no longer used)
# +03 SAST South Africa Summer Time (no longer used)
# +03 EAT East Africa Time
# 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
# 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
# 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
# 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
# commence at OOhOO on Monday 21 March 1994 and shall end at 02h00 on
# Sunday 4 September 1994.
+# From Michael Deckers (2017-04-06):
+# ... both summer and winter time are called "standard"
+# (which differs from the use in Ireland) ...
+
# From Petronella Sibeene (2007-03-30):
# http://allafrica.com/stories/200703300178.html
# While the entire country changes its time, Katima Mulilo and other
# the same time they would normally start DST, the first Sunday in September:
# https://www.timeanddate.com/news/time/namibia-new-time-zone.html
+# From Paul Eggert (2017-04-09):
+# Before the change, summer and winter time were both standard time legally.
+# However in common parlance, winter time was considered to be DST. See, e.g.:
+# http://www.nbc.na/news/namibias-winter-time-could-be-scrapped.2706
+# https://zone.my.na/news/times-are-changing-in-namibia
+# https://www.newera.com.na/2017/02/23/namibias-winter-time-might-be-repealed/
+# Use plain "WAT" and "CAT" for the time zone abbreviations, to be compatible
+# with Namibia's neighbors.
+
# RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S
-Rule Namibia 1994 only - Mar 21 0:00 0 -
-Rule Namibia 1994 2016 - Sep Sun>=1 2:00 1:00 S
-Rule Namibia 1995 2017 - Apr Sun>=1 2:00 0 -
+# Vanguard section, for zic and other parsers that support negative DST.
+Rule Namibia 1994 only - Mar 21 0:00 -1:00 WAT
+Rule Namibia 1994 2017 - Sep Sun>=1 2:00 0 CAT
+Rule Namibia 1995 2017 - Apr Sun>=1 2:00 -1:00 WAT
+# Rearguard section, for parsers that do not support negative DST.
+#Rule Namibia 1994 only - Mar 21 0:00 0 WAT
+#Rule Namibia 1994 2017 - Sep Sun>=1 2:00 1:00 CAT
+#Rule Namibia 1995 2017 - Apr Sun>=1 2:00 0 WAT
+# End of rearguard section.
+
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Africa/Windhoek 1:08:24 - LMT 1892 Feb 8
1:30 - +0130 1903 Mar
2:00 - SAST 1942 Sep 20 2:00
2:00 1:00 SAST 1943 Mar 21 2:00
2:00 - SAST 1990 Mar 21 # independence
- 2:00 - CAT 1994 Mar 21 0:00
- 1:00 Namibia WA%sT 2017 Sep 3 2:00
- 2:00 - CAT
+# Vanguard section, for zic and other parsers that support negative DST.
+ 2:00 Namibia %s
+# Rearguard section, for parsers that do not support negative DST.
+# 2:00 - CAT 1994 Mar 21 0:00
+# From Paul Eggert (2017-04-07):
+# The official date of the 2017 rule change was 2017-10-24. See:
+# http://www.lac.org.na/laws/annoSTAT/Namibian%20Time%20Act%209%20of%202017.pdf
+# 1:00 Namibia %s 2017 Oct 24
+# 2:00 - CAT
+# End of rearguard section.
# Niger
# See Africa/Lagos.
# 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.
# 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
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
+/* asctime and asctime_r a la POSIX and ISO C, except pad years before 1000. */
+
/*
** This file is in the public domain, so clarified as of
** 1996-06-05 by Arthur David Olson.
** leading zeroes to get the newline in the traditional place.
** The -4 ensures that we get four characters of output even if
** we call a strftime variant that produces fewer characters for some years.
-** The ISO C 1999 and POSIX 1003.1-2004 standards prohibit padding the year,
+** The ISO C and POSIX standards prohibit padding the year,
** but many implementations pad anyway; most likely the standards are buggy.
*/
#ifdef __GNUC__
static char buf_asctime[MAX_ASCTIME_BUF_SIZE];
-/*
-** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition.
-*/
-
char *
asctime_r(register const struct tm *timeptr, char *buf)
{
}
}
-/*
-** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition.
-*/
-
char *
asctime(register const struct tm *timeptr)
{
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
# (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
# 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
# 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]
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
# 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
# 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?
# 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).
# 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....
# 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
# There is no common English-language abbreviation for this time zone.
# Use KST, as that's what we already use for 1954-1961 in ROK.
+# From Kang Seonghoon (2018-04-29):
+# North Korea will revert its time zone from UTC+8:30 (PYT; Pyongyang
+# Time) back to UTC+9 (KST; Korea Standard Time).
+#
+# From Seo Sanghyeon (2018-04-30):
+# Rodong Sinmun 2018-04-30 announced Pyongyang Time transition plan.
+# https://www.nknews.org/kcna/wp-content/uploads/sites/5/2018/04/rodong-2018-04-30.pdf
+# ... the transition date is 2018-05-05 ... Citation should be Decree
+# No. 2232 of April 30, 2018, of the Presidium of the Supreme People's
+# Assembly, as published in Rodong Sinmun.
+# From Tim Parenti (2018-04-29):
+# It appears to be the front page story at the top in the right-most column.
+
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Asia/Seoul 8:27:52 - LMT 1908 Apr 1
8:30 - KST 1912 Jan 1
8:30 - KST 1912 Jan 1
9:00 - JST 1945 Aug 24
9:00 - KST 2015 Aug 15 00:00
- 8:30 - KST
+ 8:30 - KST 2018 May 5
+ 9:00 - KST
###############################################################################
# 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
# 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
# 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]
# [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
# 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 official 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 -
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]
# 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
# 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.
# 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
# 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
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
# 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]
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
# 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
# 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
# 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
# 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
# (1999-09-27) writes that Giles Meteorological Station uses
# South Australian time even though it's located in Western Australia.
+# From Paul Eggert (2018-04-01):
+# The Guardian Express of Perth, Australia reported today that the
+# government decided to advance the clocks permanently on January 1,
+# 2019, from UT +08 to UT +09. The article noted that an exemption
+# would be made for people aged 61 and over, who "can apply in writing
+# to have the extra hour of sunshine removed from their area." See:
+# Daylight saving coming to WA in 2019. Guardian Express. 2018-04-01.
+# https://www.communitynews.com.au/guardian-express/news/exclusive-daylight-savings-coming-wa-summer-2018/
+
# 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 ]
# "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
# 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.
# 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
# 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)
# 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
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.
# 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]
# 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
# 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
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.
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]) {
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", \
# 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.]
# 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
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
-#Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 GMT
-#Rule Eire 1981 max - Mar lastSun 1:00u 0 IST
-#Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 GMT
-#Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 GMT
-#Rule Eire 1996 max - Oct lastSun 1:00u -1:00 GMT
+Rule Eire 1971 only - Oct 31 2:00u -1:00 -
+Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 -
+Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 -
+Rule Eire 1981 max - Mar lastSun 1:00u 0 -
+Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 -
+Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 -
+Rule Eire 1996 max - Oct lastSun 1:00u -1:00 -
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
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:
-# 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.
- 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.
+# The next line is for when negative SAVE values are used.
+ 1:00 Eire IST/GMT
+# 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
###############################################################################
# Please see the 'asia' file for Asia/Nicosia.
# Czech Republic / Czechia
+#
+# From Paul Eggert (2018-04-15):
+# The source for Czech data is: Kdy začíná a končí letní čas. 2018-04-15.
+# https://kalendar.beda.cz/kdy-zacina-a-konci-letni-cas
+# We know of no English-language name for historical Czech winter time;
+# abbreviate it as "GMT", as it happened to be GMT.
+#
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
-Rule Czech 1945 only - Apr 8 2:00s 1:00 S
-Rule Czech 1945 only - Nov 18 2:00s 0 -
+Rule Czech 1945 only - Apr Mon>=1 2:00s 1:00 S
+Rule Czech 1945 only - Oct 1 2:00s 0 -
Rule Czech 1946 only - May 6 2:00s 1:00 S
Rule Czech 1946 1949 - Oct Sun>=1 2:00s 0 -
-Rule Czech 1947 only - Apr 20 2:00s 1:00 S
-Rule Czech 1948 only - Apr 18 2:00s 1:00 S
+Rule Czech 1947 1948 - Apr Sun>=15 2:00s 1:00 S
Rule Czech 1949 only - Apr 9 2:00s 1:00 S
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Europe/Prague 0:57:44 - LMT 1850
0:57:44 - PMT 1891 Oct # Prague Mean Time
- 1:00 C-Eur CE%sT 1944 Sep 17 2:00s
+ 1:00 C-Eur CE%sT 1945 May 9
+ 1:00 Czech CE%sT 1946 Dec 1 3:00
+# Vanguard section, for zic and other parsers that support negative DST.
+ 1:00 -1:00 GMT 1947 Feb 23 2:00
+# Rearguard section, for parsers that do not support negative DST.
+# 0:00 - GMT 1947 Feb 23 2:00
+# End of rearguard section.
1:00 Czech CE%sT 1979
1:00 EU CE%sT
# Use Europe/Prague also for Slovakia.
# 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 -
Rule Neth 1945 only - Apr 2 2:00s 1:00 S
Rule Neth 1945 only - Sep 16 2:00s 0 -
#
-# Amsterdam Mean Time was +00:19:32.13 exactly, but the .13 is omitted
+# Amsterdam Mean Time was +00:19:32.13, but the .13 is omitted
# below because the current format requires GMTOFF to be an integer.
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Europe/Amsterdam 0:19:32 - LMT 1835
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.
#
# 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
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
-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
# 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 ...
#
# 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....
#
# 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):
/*
** The DST rules to use if TZ has no rules and we can't load TZDEFRULES.
** Default to US rules as of 2017-05-07.
-** POSIX 1003.1 section 8.1.1 says that the default DST rules are
-** implementation dependent; for historical reasons, US rules are a
-** common default.
+** POSIX does not specify the default DST rules;
+** for historical reasons, US rules are a common default.
*/
#ifndef TZDEFRULESTRING
#define TZDEFRULESTRING ",M3.2.0,M11.1.0"
if (name[0] == ':')
++name;
+#ifdef SUPPRESS_TZDIR
+ /* Do not prepend TZDIR. This is intended for specialized
+ applications only, due to its security implications. */
+ doaccess = true;
+#else
doaccess = name[0] == '/';
+#endif
if (!doaccess) {
size_t namelen = strlen(name);
if (sizeof lsp->fullname - sizeof tzdirslash <= namelen)
/* No adjustment to transition time */
} else {
/*
- ** If summer time is in effect, and the
- ** transition time was not specified as
- ** standard time, add the summer time
- ** offset to the transition time;
- ** otherwise, add the standard time
- ** offset to the transition time.
+ ** If daylight saving time is in
+ ** effect, and the transition time was
+ ** not specified as standard time, add
+ ** the daylight saving time offset to
+ ** the transition time; otherwise, add
+ ** the standard time offset to the
+ ** transition time.
*/
/*
** Transitions from DST to DDST
#ifdef STD_INSPIRED
/*
-** IEEE Std 1003.1-1988 (POSIX) legislates that 536457599
+** IEEE Std 1003.1 (POSIX) says that 536457599
** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which
** is not the case if we are accounting for leap seconds.
** So, we provide the following conversion routines for use
.B tm_isdst
causes
.I mktime
-to presume initially that summer time (for example, Daylight Saving Time
-in the U.S.A.)
+to presume initially that daylight saving time
respectively,
is or is not in effect for the specified time.
A negative value for
.B tm_isdst
causes the
.I mktime
-function to attempt to divine whether summer time is in effect
+function to attempt to divine whether daylight saving time is in effect
for the specified time; in this case it does not use a consistent
rule and may give a different answer when later
presented with the same argument.)
int tm_year; /\(** year \- 1900 \(**/
int tm_wday; /\(** day of week (Sunday = 0) \(**/
int tm_yday; /\(** day of year (0\*(en365) \(**/
- int tm_isdst; /\(** is summer time in effect? \(**/
+ int tm_isdst; /\(** is daylight saving time in effect? \(**/
char \(**tm_zone; /\(** time zone abbreviation (optional) \(**/
long tm_gmtoff; /\(** offset from UT in seconds (optional) \(**/
.fi
.RE
.PP
.I Tm_isdst
-is non-zero if summer time is in effect.
+is non-zero if daylight saving time is in effect.
.PP
.I Tm_gmtoff
is the offset (in seconds) of the time represented
original values of the tm_wday and tm_yday components of the structure
are ignored, and the original values of the other components are not
restricted to their normal ranges. (A positive or zero value for
- tm_isdst causes mktime to presume initially that summer time (for
- example, Daylight Saving Time in the U.S.A.) respectively, is or is
- not in effect for the specified time. A negative value for tm_isdst
- causes the mktime function to attempt to divine whether summer time is
- in effect for the specified time; in this case it does not use a
- consistent rule and may give a different answer when later presented
- with the same argument.) On successful completion, the values of the
- tm_wday and tm_yday components of the structure are set appropriately,
- and the other components are set to represent the specified calendar
- time, but with their values forced to their normal ranges; the final
- value of tm_mday is not set until tm_mon and tm_year are determined.
- Mktime returns the specified calendar time; If the calendar time cannot
- be represented, it returns -1.
+ tm_isdst causes mktime to presume initially that daylight saving time
+ respectively, is or is not in effect for the specified time. A
+ negative value for tm_isdst causes the mktime function to attempt to
+ divine whether daylight saving time is in effect for the specified
+ time; in this case it does not use a consistent rule and may give a
+ different answer when later presented with the same argument.) On
+ successful completion, the values of the tm_wday and tm_yday components
+ of the structure are set appropriately, and the other components are
+ set to represent the specified calendar time, but with their values
+ forced to their normal ranges; the final value of tm_mday is not set
+ until tm_mon and tm_year are determined. Mktime returns the specified
+ calendar time; If the calendar time cannot be represented, it returns
+ -1.
Difftime returns the difference between two calendar times, (time1 -
time0), expressed in seconds.
int tm_year; /* year - 1900 */
int tm_wday; /* day of week (Sunday = 0) */
int tm_yday; /* day of year (0-365) */
- int tm_isdst; /* is summer time in effect? */
+ int tm_isdst; /* is daylight saving time in effect? */
char *tm_zone; /* time zone abbreviation (optional) */
long tm_gmtoff; /* offset from UT in seconds (optional) */
- Tm_isdst is non-zero if summer time is in effect.
+ Tm_isdst is non-zero if daylight saving time is in effect.
Tm_gmtoff is the offset (in seconds) of the time represented from UT,
with positive values indicating east of the Prime Meridian. The
-.\" Based on the UCB file whose copyright information appears below.
-.\" Copyright (c) 1989, 1991 The Regents of the University of California.
+.\" Based on the UCB file whose corrected copyright information appears below.
+.\" Copyright 1989, 1991 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" This code is derived from software contributed to Berkeley by
.IR std " and " dst
Three or more bytes that are the designation for the standard
.RI ( std )
-or summer
-.RI ( dst )
+or the alternative
+.RI ( dst ,
+such as daylight saving time)
time zone. Only
.I std
is required; if
.I dst
-is missing, then summer time does not apply in this locale.
+is missing, then daylight saving time does not apply in this locale.
Upper- and lowercase letters are explicitly allowed. Any characters
except a leading colon
.RB ( : ),
.I offset
follows
.IR dst ,
-summer time is assumed to be one hour ahead of standard time. One or
+daylight saving time is assumed to be one hour ahead of standard time. One or
more digits may be used; the value is always interpreted as a decimal
number. The hour must be between zero and 24, and the minutes (and
seconds) \*(en if present \*(en between zero and 59. If preceded by a
.q "+" .
.TP
.I rule
-Indicates when to change to and back from summer time. The
+Indicates when to change to and back from daylight saving time. The
.I rule
has the form:
.RS
.IP
where the first
.I date
-describes when the change from standard to summer time occurs and the
+describes when the change from standard to daylight saving time occurs and the
second
.I date
describes when the change back happens. Each
stands for US Eastern Standard
Time (EST), 5 hours behind UT, without daylight saving.
.TP
-.B FJT\*-12FJST,M11.1.0,M1.3.4/75
-stands for Fiji Time (FJT) and Fiji Summer Time (FJST), 12 hours ahead
+.B <+12>\*-12<+13>,M11.1.0,M1.2.1/147
+stands for Fiji time, 12 hours ahead
of UT, springing forward on November's first Sunday at 02:00, and
-falling back on January's third Thursday at 75:00 (i.e., 03:00 on the
-first Sunday on or after January 18).
+falling back on January's second Monday at 147:00 (i.e., 03:00 on the
+first Sunday on or after January 14). The abbreviations for standard
+and daylight saving time are
+.q "+12"
+and
+.q "+13".
.TP
.B IST\*-2IDT,M3.4.4/26,M10.5.0
stands for Israel Standard Time (IST) and Israel Daylight Time (IDT),
Thursday at 26:00 (i.e., 02:00 on the first Friday on or after March
23), and falling back on October's last Sunday at 02:00.
.TP
-.B WART4WARST,J1/0,J365/25
-stands for Western Argentina Summer Time (WARST), 3 hours behind UT.
+.B <\*-04>4<\*-03>,J1/0,J365/25
+stands for permanent daylight saving time, 3 hours behind UT with
+abbreviation
+.q "\*-03".
There is a dummy fall-back transition on December 31 at 25:00 daylight
saving time (i.e., 24:00 standard time, equivalent to January 1 at
00:00 standard time), and a simultaneous spring-forward transition on
January 1 at 00:00 standard time, so daylight saving time is in effect
all year and the initial
-.B WART
+.B <\*-04>
is a placeholder.
.TP
-.B WGT3WGST,M3.5.0/\*-2,M10.5.0/\*-1
-stands for Western Greenland Time (WGT) and Western Greenland Summer
-Time (WGST), 3 hours behind UT, where clocks follow the EU rules of
+.B <\*-03>3<\*-02>,M3.5.0/\*-2,M10.5.0/\*-1
+stands for time in western Greenland, 3 hours behind UT, where clocks
+follow the EU rules of
springing forward on March's last Sunday at 01:00 UT (\-02:00 local
-time) and falling back on October's last Sunday at 01:00 UT
-(\-01:00 local time).
+time, i.e., 22:00 the previous day) and falling back on October's last
+Sunday at 01:00 UT (\-01:00 local time, i.e., 23:00 the previous day).
+The abbreviations for standard and daylight saving time are
+.q "\*-03"
+and
+.q "\*-02".
.PP
If no
.I rule
file
.B posixrules
in the system time conversion information directory are used, with the
-standard and summer time offsets from UT replaced by those specified by
+standard and daylight saving time offsets from UT replaced by those specified by
the
.I offset
values in
Where:
std and dst Three or more bytes that are the designation for
- the standard (std) or summer (dst) time zone.
- Only std is required; if dst is missing, then
- summer time does not apply in this locale.
- Upper- and lowercase letters are explicitly
- allowed. Any characters except a leading colon
- (:), digits, comma (,), ASCII minus (-), ASCII
- plus (+), and NUL bytes are allowed.
- Alternatively, a designation can be surrounded by
- angle brackets < and >; in this case, the
- designation can contain any characters other than
- > and NUL.
+ the standard (std) or the alternative (dst, such
+ as daylight saving time) time zone. Only std is
+ required; if dst is missing, then daylight saving
+ time does not apply in this locale. Upper- and
+ lowercase letters are explicitly allowed. Any
+ characters except a leading colon (:), digits,
+ comma (,), ASCII minus (-), ASCII plus (+), and
+ NUL bytes are allowed. Alternatively, a
+ designation can be surrounded by angle brackets <
+ and >; in this case, the designation can contain
+ any characters other than > and NUL.
offset Indicates the value one must add to the local
time to arrive at Coordinated Universal Time.
The minutes (mm) and seconds (ss) are optional.
The hour (hh) is required and may be a single
digit. The offset following std is required. If
- no offset follows dst, summer time is assumed to
- be one hour ahead of standard time. One or more
- digits may be used; the value is always
- interpreted as a decimal number. The hour must
- be between zero and 24, and the minutes (and
+ no offset follows dst, daylight saving time is
+ assumed to be one hour ahead of standard time.
+ One or more digits may be used; the value is
+ always interpreted as a decimal number. The hour
+ must be between zero and 24, and the minutes (and
seconds) - if present - between zero and 59. If
preceded by a "-", the time zone shall be east of
the Prime Meridian; otherwise it shall be west
(which may be indicated by an optional preceding
"+".
- rule Indicates when to change to and back from summer
- time. The rule has the form:
+ rule Indicates when to change to and back from
+ daylight saving time. The rule has the form:
date/time,date/time
where the first date describes when the change
- from standard to summer time occurs and the
- second date describes when the change back
+ from standard to daylight saving time occurs and
+ the second date describes when the change back
happens. Each time field describes when, in
current local time, the change to the other time
is made. As an extension to POSIX, daylight
EST5 stands for US Eastern Standard Time (EST), 5 hours behind UT,
without daylight saving.
- FJT-12FJST,M11.1.0,M1.3.4/75
- stands for Fiji Time (FJT) and Fiji Summer Time (FJST), 12 hours
- ahead of UT, springing forward on November's first Sunday at
- 02:00, and falling back on January's third Thursday at 75:00
- (i.e., 03:00 on the first Sunday on or after January 18).
+ <+12>-12<+13>,M11.1.0,M1.2.1/147
+ stands for Fiji time, 12 hours ahead of UT, springing forward on
+ November's first Sunday at 02:00, and falling back on January's
+ second Monday at 147:00 (i.e., 03:00 on the first Sunday on or
+ after January 14). The abbreviations for standard and daylight
+ saving time are "+12" and "+13".
IST-2IDT,M3.4.4/26,M10.5.0
stands for Israel Standard Time (IST) and Israel Daylight Time
Thursday at 26:00 (i.e., 02:00 on the first Friday on or after
March 23), and falling back on October's last Sunday at 02:00.
- WART4WARST,J1/0,J365/25
- stands for Western Argentina Summer Time (WARST), 3 hours behind
- UT. There is a dummy fall-back transition on December 31 at
- 25:00 daylight saving time (i.e., 24:00 standard time,
- equivalent to January 1 at 00:00 standard time), and a
- simultaneous spring-forward transition on January 1 at 00:00
- standard time, so daylight saving time is in effect all year and
- the initial WART is a placeholder.
-
- WGT3WGST,M3.5.0/-2,M10.5.0/-1
- stands for Western Greenland Time (WGT) and Western Greenland
- Summer Time (WGST), 3 hours behind UT, where clocks follow the
- EU rules of springing forward on March's last Sunday at 01:00 UT
- (-02:00 local time) and falling back on October's last Sunday at
- 01:00 UT (-01:00 local time).
+ <-04>4<-03>,J1/0,J365/25
+ stands for permanent daylight saving time, 3 hours behind UT
+ with abbreviation "-03". There is a dummy fall-back transition
+ on December 31 at 25:00 daylight saving time (i.e., 24:00
+ standard time, equivalent to January 1 at 00:00 standard time),
+ and a simultaneous spring-forward transition on January 1 at
+ 00:00 standard time, so daylight saving time is in effect all
+ year and the initial <-04> is a placeholder.
+
+ <-03>3<-02>,M3.5.0/-2,M10.5.0/-1
+ stands for time in western Greenland, 3 hours behind UT, where
+ clocks follow the EU rules of springing forward on March's last
+ Sunday at 01:00 UT (-02:00 local time, i.e., 22:00 the previous
+ day) and falling back on October's last Sunday at 01:00 UT
+ (-01:00 local time, i.e., 23:00 the previous day). The
+ abbreviations for standard and daylight saving time are "-03"
+ and "-02".
If no rule is present in TZ, the rules specified by the
tzfile(5)-format file posixrules in the system time conversion
- information directory are used, with the standard and summer time
- offsets from UT replaced by those specified by the offset values in TZ.
+ information directory are used, with the standard and daylight saving
+ time offsets from UT replaced by those specified by the offset values
+ in TZ.
For compatibility with System V Release 3.1, a semicolon (;) may be
used to separate the rule from the rest of the specification.
# 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,
# 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
# ...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
# 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):
-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
# 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
#
# 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
** Thank you!
*/
+/*
+** zdump has been made independent of the rest of the time
+** conversion package to increase confidence in the verification it provides.
+** You can use zdump to help in verifying other implementations.
+** To do this, compile with -DUSE_LTZ=0 and link without the tz library.
+*/
+#ifndef USE_LTZ
+# define USE_LTZ 1
+#endif
+
/* This string was in the Factory zone through version 2016f. */
#define GRANDPARENTED "Local time zone must be set--see zic manual page"
#define HAVE_STRDUP 1
#endif
+#ifndef HAVE_STRTOLL
+#define HAVE_STRTOLL 1
+#endif
+
#ifndef HAVE_SYMLINK
#define HAVE_SYMLINK 1
#endif /* !defined HAVE_SYMLINK */
#ifndef INTMAX_MAX
# ifdef LLONG_MAX
typedef long long intmax_t;
-# define strtoimax strtoll
+# if HAVE_STRTOLL
+# define strtoimax strtoll
+# endif
# define INTMAX_MAX LLONG_MAX
# define INTMAX_MIN LLONG_MIN
# else
typedef long intmax_t;
-# define strtoimax strtol
# define INTMAX_MAX LONG_MAX
# define INTMAX_MIN LONG_MIN
# endif
+# ifndef strtoimax
+# define strtoimax strtol
+# endif
#endif
#ifndef PRIdMAX
#define SIZE_MAX ((size_t) -1)
#endif
-#if 2 < __GNUC__ + (96 <= __GNUC_MINOR__)
+#if 3 <= __GNUC__
# define ATTRIBUTE_CONST __attribute__ ((const))
+# define ATTRIBUTE_MALLOC __attribute__ ((__malloc__))
# define ATTRIBUTE_PURE __attribute__ ((__pure__))
# define ATTRIBUTE_FORMAT(spec) __attribute__ ((__format__ spec))
#else
# define ATTRIBUTE_CONST /* empty */
+# define ATTRIBUTE_MALLOC /* empty */
# define ATTRIBUTE_PURE /* empty */
# define ATTRIBUTE_FORMAT(spec) /* empty */
#endif
#ifndef EPOCH_OFFSET
# define EPOCH_OFFSET 0
#endif
+#ifndef RESERVE_STD_EXT_IDS
+# define RESERVE_STD_EXT_IDS 0
+#endif
+
+/* If standard C identifiers with external linkage (e.g., localtime)
+ are reserved and are not already being renamed anyway, rename them
+ as if compiling with '-Dtime_tz=time_t'. */
+#if !defined time_tz && RESERVE_STD_EXT_IDS && USE_LTZ
+# define time_tz time_t
+#endif
/*
** Compile with -Dtime_tz=T to build the tz package with a private
# 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.,
# 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
# 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
# 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
# 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:
# 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
# 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),
# 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
# 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)
# 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.
# 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
# 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.
# 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.
# ... 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 -
# 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.
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]
# "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
# 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]
# 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
# 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.
# 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
# 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
# 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
# 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):
# 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
# 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
# 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
** %Ec %EC %Ex %EX %Ey %EY
** %Od %oe %OH %OI %Om %OM
** %OS %Ou %OU %OV %Ow %OW %Oy
- ** are supposed to provide alternate
+ ** are supposed to provide alternative
** representations.
*/
goto label;
-<!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>
</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 <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>
applications requiring accurate handling of all past times everywhere,
as it would take far too much effort and guesswork to record all
details of pre-1970 civil timekeeping.
-Athough some information outside the scope of the database is
+Although some information outside the scope of the database is
collected in a file <code>backzone</code> that is distributed along
with the database proper, this file is less reliable and does not
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-2017, 2018
+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 does not always 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.
+interface that explains the names; for one example, see the
+<code>tzselect</code> 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→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→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>'.
+Some names are further qualified to help avoid confusion; for example,
+'<code>America/Indiana/Petersburg</code>' distinguishes Petersburg,
+Indiana from other Petersburgs in America.
</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>Asia/Brunei</code> to
+ <code>Asia/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,
+ do not 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>America/Costa_Rica</code> to
+ <code>America/San_Jose</code> and <code>America/Guyana</code>
+ to <code>America/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>Europe/Paris</code> to <code>Europe/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>Europe/Rome</code> to <code>Europe/Roma</code>, and
+ prefer <code>Europe/Athens</code> to the Greek
+ <code>Europe/Αθήνα</code> or the Romanized
+ <code>Europe/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>Asia/Shanghai</code> to
+ <code>Asia/Beijing</code>.
+ Among locations with similar populations, pick the best-known
+ location, e.g., prefer <code>Europe/Rome</code> to
+ <code>Europe/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>Atlantic/Canary</code> to
+ <code>Atlantic/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>America/Cayman</code> to
+ <code>America/Cayman_Islands</code> and
+ <code>America/Guatemala</code> to
+ <code>America/Guatemala_City</code>, but prefer
+ <code>America/Mexico_City</code> to
+ <code>America/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>Atlantic/St_Helena</code> to
+ <code>Atlantic/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, do not change the existing name <code>Europe/Rome</code> to
+ <code>Europe/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° 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°
+east longitude, this relationship is not exact.
</p>
<p>
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
+ space and '<code>?</code>', but these characters have a
+ special meaning to the
+ <a href="https://en.wikipedia.org/wiki/Unix_shell">UNIX shell</a>
+ 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–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–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–1932, DMT/IST for Dublin/Dunsink Mean Time and Irish Summer Time
-1880–1916, MMT/MST/MDST for Moscow 1880–1919, and RMT/LST
-for Riga Mean Time and Latvian Summer time 1880–1926.
-An extra-special case is SET for Swedish Time (<em>svensk
-normaltid</em>) 1879–1899, 3° 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–1932,
+ DMT/IST for Dublin/Dunsink Mean Time and Irish Summer Time
+ 1880–1916,
+ MMT/MST/MDST for Moscow 1880–1919, and
+ RMT/LST for Riga Mean Time and Latvian Summer time 1880–1926.
+ An extra-special case is SET for Swedish Time (<em>svensk
+ normaltid</em>) 1879–1899, 3° 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&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–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&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 do not
+ 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 is 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 cannot 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><+09></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><+09></code>';
+ this allows "<code>+</code>" and "<code>-</code>" in the names.
</dd>
<dt><var>offset</var></dt><dd>
- is of the form
- '<code>[±]<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≤<var>hh</var>≤24.
- The default DST offset is one hour ahead of standard time.
+ is of the form
+ '<code>[±]<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≤<var>hh</var>≤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≤<var>n</var>≤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≤<var>n</var>≤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]≤<var>d</var>≤6[Saturday], 1≤<var>n</var>≤5, 1≤<var>m</var>≤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]≤<var>d</var>≤6[Saturday], 1≤<var>n</var>≤5,
+ 1≤<var>m</var>≤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 is 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 – 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 –
- 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 do not
+ provide <code>tzsetwall</code>, you will not 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 – directly or
+ indirectly – and there is no <code>TZ</code> environment
+ variable; portable applications should not, however, rely on this
+ behavior since it is not the way <a
+ href="https://en.wikipedia.org/wiki/UNIX_System_V#SVR2"><abbr>SVR2</abbr></a>
+ 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 – directly or indirectly –
- 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(&clock)->tm_zone</code>
- (if <code>TM_ZONE</code> is defined) or
- <code>tzname[localtime(&clock)->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 is 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(&clock)->tm_zone</code>
+ (if <code>TM_ZONE</code> is defined) or
+ <code>tzname[localtime(&clock)->tm_isdst]</code>
+ (if <code>HAVE_TZNAME</code> is defined) to learn the correct time
+ zone abbreviation to use.
+ </li>
+ <li>
+ The <a
+ href="https://en.wikipedia.org/wiki/History_of_the_Berkeley_Software_Distribution#4.2BSD"><abbr>4.2BSD</abbr></a>
+ <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 do not 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" – 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" – 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
-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.
+extended the time zone database further into the past.
+An excellent resource in this area is Edward M. Reingold
+and Nachum Dershowitz, <cite><a
+href="https://www.cambridge.org/fr/academic/subjects/computer-science/computing-general-interest/calendrical-calculations-ultimate-edition-4th-edition">Calendrical
+Calculations: The Ultimate Edition</a></cite>, Cambridge University Press (2018).
+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 kept Mars time on
+and off during the
+<a href="https://en.wikipedia.org/wiki/Mars_Pathfinder#End_of_mission">Mars
+Pathfinder</a> mission.
+Some of their family members 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>
emerge a bit too early from the titular enclosure.
</li>
<li>
-The 1960s ITC television series <em>The Prisoner</em> included an episode
-entitled "The Chimes of Big Ben" in which our protagonist tumbled to
+"The Chimes of Big Ben", <em>The Prisoner</em>, episode 2, ITC, 1967-10-06.
+Our protagonist tumbles to
the fraudulent nature of a Poland-to-England escape upon hearing "Big
Ben" chiming on Polish local time.
</li>
<li>
-The series <em>Seinfeld</em> included an episode entitled "The Susie," first
-broadcast 1997-02-13, in which Kramer decides that daylight saving time
+"The Susie", <em>Seinfeld</em>, season 8, episode 15, NBC, 1997-02-13.
+Kramer decides that daylight saving time
isn't coming fast enough, so he sets his watch ahead an hour.
</li>
<li>
-The "20 Hours in America" episode of <em>The West Wing</em>,
-
first aired 2002-09-25, contained a <a
+"20 Hours in America", <em>The West Wing</em>, season 4, episodes 1–2,
+2002-09-25, contained a <a
href="https://www.youtube.com/watch?v=-J1NHzQ1sgc">scene</a> that
saw White House staffers stranded in Indiana; they thought they had time to
catch Air Force One but were done in by intra-Indiana local time changes.
The applicability of a contract hinges on the
time zone associated with a video timestamp.
</li>
+<li>
+"Justice", <em>Veep</em>, season 6, episode 4, HBO, 2017-05-07.
+Jonah's inability to understand DST ends up impressing a wealthy
+backer who sets him up for a 2020 presidential run.
+</li>
</ul>
<h2>Books, plays, and magazines</h2>
<ul>
<body>
<h1>Sources for time zone and daylight saving time data</h1>
<p>
-Time zone and daylight saving rules are controlled by individual
+<a href="https://en.wikipedia.org/wiki/Time_zone">Time zone</a> and
+<a href="https://en.wikipedia.org/wiki/Daylight_saving_time">daylight-saving</a>
+rules are controlled by individual
governments. They are sometimes changed with little notice, and their
histories and planned futures are often recorded only fitfully. Here
is a summary of attempts to organize and record relevant data in this
that represent the history of local time
for many representative locations around the globe.
It is updated periodically to reflect changes made by political bodies
-to <a href="https://en.wikipedia.org/wiki/Time_zone">time zone</a>
-boundaries and
-<a href="https://en.wikipedia.org/wiki/Daylight_saving_time">daylight-saving</a>
-rules.
-This database (often called <code>zoneinfo</code> or
-<code><abbr>tz</abbr></code>)
+to time zone boundaries and daylight saving rules.
+This database (known as <code><abbr>tz</abbr></code>,
+<code><abbr>tzdb</abbr></code>, or <code>zoneinfo</code>)
is used by several implementations,
including
<a href="https://www.gnu.org/software/libc/">the
release in a single-tarball format containing extra data
useful for regression testing:</p>
<pre style="margin-left: 2em"><code>wget <a href="https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz">https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz</a>
-<a href="http://www.nongnu.org/lzip/">lzip</a> -dc tzdb-latest.tar.lz | tar -xf -
+<a href="https://www.nongnu.org/lzip/">lzip</a> -dc tzdb-latest.tar.lz | tar -xf -
</code></pre>
<p>These commands use convenience links to the latest release
of the <code><abbr>tz</abbr></code> database hosted by the
The releases are also available in an
<a href="ftp://ftp.iana.org/tz/releases/"><abbr
title="File Transfer Protocol">FTP</abbr> directory</a> via a
-less-secure protocol .</p>
+less-secure protocol.</p>
<p>Alternatively, a development repository of code and data can be
retrieved from <a href="https://github.com">GitHub</a> via the shell
command:</p>
latest <code><abbr>tz</abbr></code> data have also been published
for <a href="https://www.ibm.com/developerworks/aix/library/au-aix-olson-time-zone/index.html"><abbr>AIX</abbr></a>,
<a
+href="https://play.google.com/store/apps/details?id=com.google.android.timezone.data">Android</a>,
+<a
href="http://userguide.icu-project.org/datetime/timezone"><abbr
title="International Components for Unicode">ICU</abbr></a>,
<a href="https://developer.ibm.com/javasdk/support/dst/jtzu/"><abbr>IBM</abbr></a>
Java, <a href="http://www.joda.org/joda-time/tz_update.html">Joda-Time</a>, <a
href="https://dev.mysql.com/doc/refman/en/time-zone-support.html">MySQL</a>,
and <a
-href="http://nodatime.org/userguide/tzdb">Noda Time</a> (see below).
+href="https://nodatime.org/userguide/tzdb">Noda Time</a> (see below).
</p>
<p>Sources for the <code><abbr>tz</abbr></code> database are
<a href="https://en.wikipedia.org/wiki/UTF-8"><abbr
which can be modified by common text editors such
as <a href="https://www.gnu.org/software/emacs/">GNU Emacs</a>,
<a href="https://wiki.gnome.org/Apps/Gedit">gedit</a>, and
-<a href="http://www.vim.org">vim</a>.
+<a href="https://www.vim.org">vim</a>.
Specialized source-file editing can be done via the
<a href="https://packagecontrol.io/packages/zoneinfo">Sublime
zoneinfo</a> package for <a
<ul>
<li><a href="https://time.is">Time.is</a> shows locations'
time and zones.</li>
-<li><a href="https://www.timejones.com">TimeJones.com</a>
-and <a href="https://timezoneconverterapp.com">Time Zone Converter</a>
+<li><a href="https://www.timejones.com">TimeJones.com</a>,
+<a href="https://timezoneconverterapp.com">Time Zone Converter</a> and
+<a href="http://worldclock.com">The World Clock</a>
are time zone converters.</li>
<li><a
href="http://twiki.org/cgi-bin/xtra/tzdatepick.html">Date and Time Gateway</a>
timezone information for all countries</a> displays tables of DST rules.
<li><a href="https://www.timeanddate.com/worldclock/">The World Clock –
Worldwide</a> lets you sort zone names and convert times.</li>
-<li><a href="http://www.zeitverschiebung.net/en/">Time Difference</a>
+<li><a href="https://24timezones.com">24TimeZones</a> has a world
+time map and a time converter.</li>
+<li><a href="https://www.zeitverschiebung.net/en/">Time Difference</a>
calculates the current time difference between locations.</li>
<li><a href="http://www.wx-now.com">Weather Now</a> and
<a href="http://www.thetimenow.com">The Time Now</a> list the weather too.</li>
title="Extensible Markup Language">XML</abbr></a> format, and a variant
<a href="https://tools.ietf.org/html/rfc7265">jCal</a>
(Internet <abbr>RFC</abbr> 7265)
-uses <a href="http://www.json.org"><abbr
+uses <a href="http
s://www.json.org"><abbr
title="JavaScript Object Notation">JSON</abbr></a> format.</li>
</ul>
<h2 id="compilers">Other <code><abbr>tz</abbr></code> compilers</h2>
<li><abbr>ICU</abbr> (mentioned <a href="#ICU">above</a>) contains compilers and
Java-based libraries.</li>
</ul>
-<li><a href="http://nodatime.org">Noda Time – Date and
+<li><a href="https://nodatime.org">Noda Time – Date and
time <abbr>API</abbr> for .NET</a>
and <a href="http://www.babiej.demon.nl/Tz4Net/main.htm">TZ4Net</a>
are similar to Joda-Time and Time4J, but for the .NET framework instead of
<li><a href="https://en.wikipedia.org/wiki/JavaScript">JavaScript</a>-based
compilers and libraries include:
<ul>
+<li><a
+href="https://github.com/kshetline/compact-time-zone-generator">CompactTimeZoneGenerator</a>
+compiles time zone data into a compact form designed for
+JavaScript. It is freely available under a combination of
+the <abbr>MIT</abbr> license and the Apache License.</li>
<li><a href="https://momentjs.com/timezone/">Moment Timezone</a> is a
plugin for the <a href="https://momentjs.com">Moment.js</a> date
manipulation library. It is freely available under the <abbr>MIT</abbr>
time stamps from one time zone or format to another.
It is used by <a href="https://secure.php.net"><abbr
title="PHP: Hypertext Preprocessor">PHP</abbr></a>,
-<a href="http://hhvm.com"><abbr title="HipHop Virtual Machine">HHVM</abbr></a>,
+<a href="http
s://hhvm.com"><abbr title="HipHop Virtual Machine">HHVM</abbr></a>,
and <a href="https://www.mongodb.com">MongoDB</a>.
It is freely available under the <abbr>MIT</abbr> license.</li>
<li><a href="https://github.com/bigeasy/timezone">Timezone</a> is a
which stores time zone data in the
<a href="https://en.wikipedia.org/wiki/Windows_Registry">Windows Registry</a>. The
<a
-href="http://unicode.org/cldr/charts/latest/supplemental/zone_tzid.html">Zone →
+href="https://unicode.org/cldr/charts/latest/supplemental/zone_tzid.html">Zone →
Tzid table</a> or <a
href="https://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml"><abbr>XML</abbr>
file</a> of the <abbr>CLDR</abbr> data maps proprietary zone IDs
Java</a> contains a copy of a subset of a recent
<code><abbr>tz</abbr></code> database in a
Java-specific format.</li>
-<li><a href="http://www.relativedata.com/time-zone-master">Time Zone
+<li><a href="https://www.relativedata.com/time-zone-master">Time Zone
Master</a> is a Microsoft Windows clock program that can automatically
download, compile and use <code>tz</code> releases. The Basic version
is free.</li>
<li><a href="https://www.astro.com/atlas">Time-zone Atlas</a>
is Astrodienst's Web version of Shanks and Pottenger's
time zone history atlases also published in <a
-href="http://astrocom.com/astrology-products/software/acs-atlas-software">software</a>
-form by <a href="http://astrocom.com">ACS-Starcrafts</a>.
+href="https://astrocom.com/astrology-products/software/acs-atlas-software">software</a>
+form by <a href="https://astrocom.com">ACS-Starcrafts</a>.
These atlases are extensive but unreliable, as Shanks appears to have
guessed many <abbr>UT</abbr> offsets and transitions. The atlases cite no
sources and do not indicate which entries are guesswork.</li>
its own <code>tztab</code>(4) format.</li>
<li>Microsoft Windows has proprietary data mentioned
<a href="#System.TimeZoneInfo">above</a>.</li>
-<li><a href="http://www.worldtimeserver.com">World Time Server</a>
+<li><a href="https://www.worldtimeserver.com">World Time Server</a>
is another time zone database.</li>
<li><a href="http://tycho.usno.navy.mil/tzones.html">World Time Zones</a>
contains data from the Time Service Department of the
of the University of Texas at Austin has copies of
recent editions.
The pictorial quality is good,
-but the maps do not indicate summer time,
+but the maps do not indicate daylight saving time,
and parts of the data are a few years out of date.</li>
-<li><a href="http://www.worldtimezone.com">Current time around the world
+<li><a href="https://www.worldtimezone.com">Current time around the world
and standard time zones map of the world</a>
has several fancy time zone maps; it covers Russia particularly well.
The maps' pictorial quality is not quite as good as the
<abbr>CIA</abbr>'s
but the maps are more up to date.</li>
<li><a
-href="http://blog.poormansmath.net/how-much-is-time-wrong-around-the-world/">How
+href="https://blog.poormansmath.net/how-much-is-time-wrong-around-the-world/">How
much is time wrong around the world?</a> maps the difference between
mean solar and standard time, highlighting areas such as western China
where the two differ greatly. It's a bit out of date, unfortunately.</li>
<li><a href="http://home.kpn.nl/vanadovv/time/Multizones.html">Time
zone boundaries for multizone countries</a> summarizes legal
boundaries between time zones within countries.</li>
-<li>Manifold.net's <a
-href="http://manifold.net/info/freestuff.shtml">Free Downloads for
-Manifold System Users</a> includes a Manifold-format map of
+<li><a href="http://manifold.net/info/freestuff.shtml">Manifold Software
+– GIS and Database Tools</a> includes a Manifold-format map of
world time zone boundaries distributed under the
<abbr>GPL</abbr>.</li>
<li>A ship within the <a
<dd>The Hydrographic and Oceanographic Service of the Chilean Navy publishes a
<a href="http://www.horaoficial.cl/historia_hora.html" hreflang="es">history of
Chile's official time (in Spanish)</a>.</dd>
+<dt>Czech Republic</dt>
+<dd><a href="https://kalendar.beda.cz/kdy-zacina-a-konci-letni-cas"
+hreflang="cs">When daylight saving time starts and ends (in Czech)</a>
+summarizes and cites historical DST regulations.</dd>
<dt>Germany</dt>
<dd>The National Institute for Science and Technology maintains the <a
href="https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-legal-time-in-germany.html">Realisation
<dd>The Department of Transportation's <a
href="https://www.transportation.gov/regulations/recent-time-zone-proceedings">Recent
Time Zone Proceedings</a> lists changes to time zone boundaries.</dd>
+<dt>Uruguay</dt>
+<dd>The Oceanography, Hydrography, and Meteorology Service of the Uruguayan
+Navy (SOHMA) publishes an annual <a
+href="http://www.armada.mil.uy/Pagina/institucion/dimat/sohma/almanaque.html" hreflang="es">almanac
+(in Spanish)</a>.</dd>
</dl>
<h2 id="precision">Precision timekeeping</h2>
<ul>
href="http://leapsecond.com/hpan/an1289.pdf">The
Science of Timekeeping</a> is a thorough introduction
to the theory and practice of precision timekeeping.</li>
+<li><a href="https://doi.org/10.1007/978-3-319-59909-0">The Science of
+Time 2016</a> contains several freely-readable papers.</li>
<li><a href="http://www.ntp.org"><abbr
title="Network Time Protocol">NTP</abbr>: The Network
Time Protocol</a> (Internet <abbr>RFC</abbr> 5905)
option for a server to configure
a client's time zone and daylight saving settings automatically.</li>
<li><a
-href="http://www.cv.nrao.edu/~rfisher/Ephemerides/times.html">Astronomical
+href="https://www.cv.nrao.edu/~rfisher/Ephemerides/times.html">Astronomical
Times</a> explains more abstruse astronomical time scales like
<abbr title="Terrestrial Dynamic Time">TDT</abbr>,
<abbr title="Geocentric Coordinate Time">TCG</abbr>, and
<abbr title="Barycentric Dynamic Time">TDB</abbr>.
-<a href="http://www.ucolick.org/~sla/leapsecs/timescales.html">Time
+<a href="https://www.ucolick.org/~sla/leapsecs/timescales.html">Time
Scales</a> goes into more detail, particularly for historical variants.</li>
<li>The <a href="https://www.iau.org"><abbr
title="International Astronomical Union">IAU</abbr></a>'s <a
discussed further in
<a href="https://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf">The
leap second: its history and possible future</a>.
-<a href="http://www.ucolick.org/~sla/leapsecs/"><abbr>UTC</abbr>
+<a href="http
s://www.ucolick.org/~sla/leapsecs/"><abbr>UTC</abbr>
might be redefined
without Leap Seconds</a> gives pointers on this
contentious issue, which was active until 2015 and could become active
contains French translations for "Eastern European Summer Time",
"<abbr title="Eastern European Summer Time">EEST</abbr>", and
"Bucharest". Its
-<a href="http://unicode.org/cldr/charts/latest/by_type/">by-type
+<a href="https://unicode.org/cldr/charts/latest/by_type/">by-type
charts</a> show these values for many locales. Data values are available in
both <abbr title="Locale Data Markup Language">LDML</abbr>
(an <abbr>XML</abbr> format) and <abbr>JSON</abbr>.
use two minor extensions to the POSIX TZ format, as described in
.BR newtzset (3).
First, the hours part of its transition times may be signed and range from
-\-167 through 167 instead of the POSIX-required unsigned values
+\*-167 through 167 instead of the POSIX-required unsigned values
from 0 through 24. Second, DST is in effect all year if it starts
January 1 at 00:00 and ends December 31 at 24:00 plus the difference
between daylight saving and standard time.
For version-3-format time zone files, the POSIX-TZ-style string may use
two minor extensions to the POSIX TZ format, as described in
newtzset(3). First, the hours part of its transition times may be
- signed and range from -167 through 167 instead of the POSIX-required
+ signed and range from 167 through 167 instead of the POSIX-required
unsigned values from 0 through 24. Second, DST is in effect all year
if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the
difference between daylight saving and standard time.
#include "version.h"
-/*
-** This code has been made independent of the rest of the time
-** conversion package to increase confidence in the verification it provides.
-** You can use this code to help in verifying other implementations.
-** To do this, compile with -DUSE_LTZ=0 and link without the tz library.
-*/
-
#ifndef NETBSD_INSPIRED
# define NETBSD_INSPIRED 1
#endif
-#ifndef USE_LTZ
-# define USE_LTZ 1
-#endif
#include "private.h"
#include <stdio.h>
/* Return a pointer to a newly allocated buffer of size SIZE, exiting
on failure. SIZE should be nonzero. */
-static void *
+static void * ATTRIBUTE_MALLOC
xmalloc(size_t size)
{
void *p = malloc(size);
A rule line has the form
.nf
.ti +.5i
-.ta \w'Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'1973\0\0'u +\w'TYPE\0\0'u +\w'Apr\0\0'u +\w'lastSun\0\0'u +\w'2:00\0\0'u +\w'SAVE\0\0'u
+.ta \w'Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'1973\0\0'u +\w'TYPE\0\0'u +\w'Apr\0\0'u +\w'lastSun\0\0'u +\w'2:00s\0\0'u +\w'1:00d\0\0'u
.sp
Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
.sp
For example:
.ti +.5i
.sp
-Rule US 1967 1973 \*- Apr lastSun 2:00 1:00 D
+Rule US 1967 1973 \*- Apr lastSun 2:00s 1:00d D
.sp
.fi
The fields that make up a rule line are:
.nf
.in +.5i
.sp
-.ta \w'01:28:13\0\0'u
+.ta \w'00:19:32.13\0\0'u
2 time in hours
2:00 time in hours and minutes
01:28:14 time in hours, minutes, and seconds
+00:19:32.13 time with fractional seconds
15:00 24-hour format time (for times after noon)
260:00 260 hours after 00:00
\*-2:30 2.5 hours before 00:00
.sp
where hour 0 is midnight at the start of the day,
and hour 24 is midnight at the end of the day.
+Although
+.I zic
+rounds times to the nearest integer second
+(breaking ties to the even integer), the fractions may be useful
+to other applications requiring greater precision.
+The source format does not specify any maximum precision.
Any of these forms may be followed by the letter
.B w
if the given time is local
.TP
.B SAVE
Gives the amount of time to be added to local standard time when the rule is in
-effect.
+effect, and whether the resulting time is standard or daylight saving.
This field has the same format as the
.B AT
field
-(although, of course, the
-suffixes are not used).
+except with a different set of suffix letters:
+.B s
+for standard time and
+.B d
+for daylight saving time.
+The suffix letter is typically omitted, and defaults to
+.B s
+if the offset is zero and to
+.B d
+otherwise.
Negative offsets are allowed; in Ireland, for example, daylight saving
time is observed in winter and has a negative offset relative to
Irish Standard Time.
-Only the sum of standard time and this amount matters; for example,
+The offset is merely added to standard time; for example,
.I zic
does not distinguish a 10:30 standard time plus an 0:30
.B SAVE
.TP
.B RULES
The name of the rules that apply in the time zone or,
-alternately, an amount of time to add to local standard time.
+alternatively, a field in the same format as a rule-line SAVE column,
+giving of the amount of time to be added to local standard time
+effect, and whether the resulting time is standard or daylight saving.
If this field is
.B \*-
then standard time always applies in the time zone.
is used to show where the
.q "variable part"
of the time zone abbreviation goes.
-Alternately, a format can use the pair of characters
+Alternatively, a format can use the pair of characters
.B %z
to stand for the UT offset in the form
.RI \(+- hh ,
and
.I ss
are the hours, minutes, and seconds east (+) or west (\(mi) of UT.
-Alternately,
+Alternatively,
a slash (/)
separates standard and daylight abbreviations.
To conform to POSIX, a time zone abbreviation should contain only
field in some zone line.
The
.B LINK-NAME
-field is used as an alternate name for that zone;
+field is used as an alternative name for that zone;
it has the same syntax as a zone line's
.B NAME
field.
A rule line has the form
- Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
+ Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
For example:
- Rule US 1967 1973 - Apr lastSun 2:00 1:00 D
+ Rule US 1967 1973 - Apr lastSun 2:00s 1:00d D
The fields that make up a rule line are:
AT Gives the time of day at which the rule takes effect.
Recognized forms include:
- 2 time in hours
- 2:00 time in hours and minutes
- 01:28:14 time in hours, minutes, and seconds
- 15:00 24-hour format time (for times after noon)
- 260:00 260 hours after 00:00
- -2:30 2.5 hours before 00:00
- - equivalent to 0
+ 2 time in hours
+ 2:00 time in hours and minutes
+ 01:28:14 time in hours, minutes, and seconds
+ 00:19:32.13 time with fractional seconds
+ 15:00 24-hour format time (for times after noon)
+ 260:00 260 hours after 00:00
+ -2:30 2.5 hours before 00:00
+ - equivalent to 0
where hour 0 is midnight at the start of the day, and hour 24
- is midnight at the end of the day. Any of these forms may be
+ is midnight at the end of the day. Although zic rounds times
+ to the nearest integer second (breaking ties to the even
+ integer), the fractions may be useful to other applications
+ requiring greater precision. The source format does not
+ specify any maximum precision. Any of these forms may be
followed by the letter w if the given time is local "wall
clock" time, s if the given time is local "standard" time, or u
(or g or z) if the given time is universal time; in the absence
the specified date and time of day.
SAVE Gives the amount of time to be added to local standard time
- when the rule is in effect. This field has the same format as
- the AT field (although, of course, the suffixes are not used).
- Negative offsets are allowed; in Ireland, for example, daylight
- saving time is observed in winter and has a negative offset
- relative to Irish Standard Time. Only the sum of standard time
- and this amount matters; for example, zic does not distinguish
- a 10:30 standard time plus an 0:30 SAVE from a 10:00 standard
- time plus a 1:00 SAVE.
+ when the rule is in effect, and whether the resulting time is
+ standard or daylight saving. This field has the same format as
+ the AT field except with a different set of suffix letters: s
+ for standard time and d for daylight saving time. The suffix
+ letter is typically omitted, and defaults to s if the offset is
+ zero and to d otherwise. Negative offsets are allowed; in
+ Ireland, for example, daylight saving time is observed in
+ winter and has a negative offset relative to Irish Standard
+ Time. The offset is merely added to standard time; for
+ example, zic does not distinguish a 10:30 standard time plus an
+ 0:30 SAVE from a 10:00 standard time plus a 1:00 SAVE.
LETTER/S
Gives the "variable part" (for example, the "S" or "D" in "EST"
subtracted from UT.
RULES The name of the rules that apply in the time zone or,
- alternately, an amount of time to add to local standard time. If
- this field is - then standard time always applies in the time
- zone. When an amount of time is given, only the sum of standard
- time and this amount matters.
+ alternatively, a field in the same format as a rule-line SAVE
+ column, giving of the amount of time to be added to local
+ standard time effect, and whether the resulting time is standard
+ or daylight saving. If this field is - then standard time always
+ applies in the time zone. When an amount of time is given, only
+ the sum of standard time and this amount matters.
FORMAT
The format for time zone abbreviations in this time zone. The
pair of characters %s is used to show where the "variable part"
- of the time zone abbreviation goes. Alternately, a format can
+ of the time zone abbreviation goes. Alternatively, a format can
use the pair of characters %z to stand for the UT offset in the
form +-hh, +-hhmm, or +-hhmmss, using the shortest form that does
not lose information, where hh, mm, and ss are the hours,
- minutes, and seconds east (+) or west (-) of UT. Alternately, a
- slash (/) separates standard and daylight abbreviations. To
+ minutes, and seconds east (+) or west (-) of UT. Alternatively,
+ a slash (/) separates standard and daylight abbreviations. To
conform to POSIX, a time zone abbreviation should contain only
alphanumeric ASCII characters, "+" and "-".
Link Europe/Istanbul Asia/Istanbul
The TARGET field should appear as the NAME field in some zone line.
- The LINK-NAME field is used as an alternate name for that zone; it has
- the same syntax as a zone line's NAME field.
+ The LINK-NAME field is used as an alternative name for that zone; it
+ has the same syntax as a zone line's NAME field.
Except for continuation lines, lines may appear in any order in the
input. However, the behavior is unspecified if multiple zone or link
#else
#define MKDIR_UMASK 0755
#endif
+/* Port to native MS-Windows and to ancient UNIX. */
+#if !defined S_ISDIR && defined S_IFDIR && defined S_IFMT
+# define S_ISDIR(mode) (((mode) & S_IFMT) == S_IFDIR)
+#endif
#if HAVE_SYS_WAIT_H
#include <sys/wait.h> /* for WIFEXITED and WEXITSTATUS */
/* or wall clock time if 0 */
bool r_todisgmt; /* above is GMT if 1 */
/* or local time if 0 */
- zic_t r_stdoff; /* offset from standard time */
+ bool r_isdst; /* is this daylight saving time? */
+ zic_t r_stdoff; /* offset from default time (which is
+ usually standard time) */
const char * r_abbrvar; /* variable part of abbreviation */
bool r_todo; /* a rule to do (used in outzone) */
const char * z_name;
zic_t z_gmtoff;
- const char * z_rule;
+ char * z_rule;
const char * z_format;
char z_format_specifier;
+ bool z_isdst;
zic_t z_stdoff;
struct rule * z_rules;
static char ** getfields(char * buf);
static zic_t gethms(const char * string, const char * errstring,
bool);
+static zic_t getstdoff(char *, bool *);
static void infile(const char * filename);
static void inleap(char ** fields, int nfields);
static void inlink(char ** fields, int nfields);
return ptr;
}
-static void *
+static void * ATTRIBUTE_MALLOC
emalloc(size_t size)
{
return memcheck(malloc(size));
return memcheck(realloc(ptr, size));
}
-static char *
+static char * ATTRIBUTE_MALLOC
ecpyalloc (char const *str)
{
return memcheck(strdup(str));
char *linkalloc = absolute ? NULL : relname(fromfield, tofield);
char const *contents = absolute ? fromfield : linkalloc;
int symlink_errno = symlink(contents, tofield) == 0 ? 0 : errno;
- if (symlink_errno == ENOENT && !todirs_made) {
+ if (!todirs_made
+ && (symlink_errno == ENOENT || symlink_errno == ENOTSUP)) {
mkdirs(tofield, true);
- symlink_errno = symlink(contents, tofield) == 0 ? 0 : errno;
+ if (symlink_errno == ENOENT)
+ symlink_errno = symlink(contents, tofield) == 0 ? 0 : errno;
}
free(linkalloc);
if (symlink_errno == 0) {
** Maybe we have a local standard time offset.
*/
eat(zp->z_filename, zp->z_linenum);
- zp->z_stdoff = gethms(zp->z_rule, _("unruly zone"),
- true);
+ zp->z_stdoff = getstdoff(zp->z_rule, &zp->z_isdst);
/*
** Note, though, that if there's no rule,
** a '%s' in the format is a bad thing.
gethms(char const *string, char const *errstring, bool signable)
{
zic_t hh;
- int mm, ss, sign;
- char xs;
+ int sign, mm = 0, ss = 0;
+ char hhx, mmx, ssx, xr = '0', xs;
+ int tenths = 0;
+ bool ok = true;
if (string == NULL || *string == '\0')
return 0;
sign = -1;
++string;
} else sign = 1;
- if (sscanf(string, "%"SCNdZIC"%c", &hh, &xs) == 1)
- mm = ss = 0;
- else if (sscanf(string, "%"SCNdZIC":%d%c", &hh, &mm, &xs) == 2)
- ss = 0;
- else if (sscanf(string, "%"SCNdZIC":%d:%d%c", &hh, &mm, &ss, &xs)
- != 3) {
+ switch (sscanf(string,
+ "%"SCNdZIC"%c%d%c%d%c%1d%*[0]%c%*[0123456789]%c",
+ &hh, &hhx, &mm, &mmx, &ss, &ssx, &tenths, &xr, &xs)) {
+ default: ok = false; break;
+ case 8:
+ ok = '0' <= xr && xr <= '9';
+ /* fallthrough */
+ case 7:
+ ok &= ssx == '.';
+ if (ok && noise)
+ warning(_("fractional seconds rejected by"
+ " pre-2018 versions of zic"));
+ /* fallthrough */
+ case 5: ok &= mmx == ':'; /* fallthrough */
+ case 3: ok &= hhx == ':'; /* fallthrough */
+ case 1: break;
+ }
+ if (!ok) {
error("%s", errstring);
return 0;
}
error(_("time overflow"));
return 0;
}
+ ss += 5 + ((ss ^ 1) & (xr == '0')) <= tenths; /* Round to even. */
if (noise && (hh > HOURSPERDAY ||
(hh == HOURSPERDAY && (mm != 0 || ss != 0))))
warning(_("values over 24 hours not handled by pre-2007 versions of zic"));
sign * (mm * SECSPERMIN + ss));
}
+static zic_t
+getstdoff(char *field, bool *isdst)
+{
+ int dst = -1;
+ zic_t stdoff;
+ size_t fieldlen = strlen(field);
+ if (fieldlen != 0) {
+ char *ep = field + fieldlen - 1;
+ switch (*ep) {
+ case 'd': dst = 1; *ep = '\0'; break;
+ case 's': dst = 0; *ep = '\0'; break;
+ }
+ }
+ stdoff = gethms(field, _("invalid saved time"), true);
+ *isdst = dst < 0 ? stdoff != 0 : dst;
+ return stdoff;
+}
+
static void
inrule(char **fields, int nfields)
{
}
r.r_filename = filename;
r.r_linenum = linenum;
- r.r_stdoff = gethms(fields[RF_STDOFF], _("invalid saved time"), true);
+ r.r_stdoff = getstdoff(fields[RF_STDOFF], &r.r_isdst);
rulesub(&r, fields[RF_LOYEAR], fields[RF_HIYEAR], fields[RF_COMMAND],
fields[RF_MONTH], fields[RF_DAY], fields[RF_TOD]);
r.r_name = ecpyalloc(fields[RF_NAME]);
static size_t
doabbr(char *abbr, struct zone const *zp, char const *letters,
- zic_t stdoff, bool doquotes)
+ bool isdst, zic_t stdoff, bool doquotes)
{
register char * cp;
register char * slashp;
else if (!letters)
letters = "%s";
sprintf(abbr, format, letters);
- } else if (stdoff != 0) {
+ } else if (isdst) {
strcpy(abbr, slashp + 1);
} else {
memcpy(abbr, format, slashp - format);
}
if (rp->r_todisgmt)
tod += gmtoff;
- if (rp->r_todisstd && rp->r_stdoff == 0)
+ if (rp->r_todisstd && !rp->r_isdst)
tod += dstoff;
if (tod != 2 * SECSPERMIN * MINSPERHOUR) {
*result++ = '/';
continue;
if (rp->r_yrtype != NULL)
continue;
- if (rp->r_stdoff == 0) {
+ if (!rp->r_isdst) {
if (stdrp == NULL)
stdrp = rp;
else return -1;
register struct rule *stdabbrrp = NULL;
for (i = 0; i < zp->z_nrules; ++i) {
rp = &zp->z_rules[i];
- if (rp->r_stdoff == 0 && rule_cmp(stdabbrrp, rp) < 0)
+ if (!rp->r_isdst && rule_cmp(stdabbrrp, rp) < 0)
stdabbrrp = rp;
if (rule_cmp(stdrp, rp) < 0)
stdrp = rp;
if (stdrp != NULL && stdrp->r_hiyear == 2037)
return YEAR_BY_YEAR_ZONE;
- if (stdrp != NULL && stdrp->r_stdoff != 0) {
+ if (stdrp != NULL && stdrp->r_isdst) {
/* Perpetual DST. */
dstr.r_month = TM_JANUARY;
dstr.r_dycode = DC_DOM;
dstr.r_dayofmonth = 1;
dstr.r_tod = 0;
dstr.r_todisstd = dstr.r_todisgmt = false;
+ dstr.r_isdst = stdrp->r_isdst;
dstr.r_stdoff = stdrp->r_stdoff;
dstr.r_abbrvar = stdrp->r_abbrvar;
stdr.r_month = TM_DECEMBER;
stdr.r_dayofmonth = 31;
stdr.r_tod = SECSPERDAY + stdrp->r_stdoff;
stdr.r_todisstd = stdr.r_todisgmt = false;
+ stdr.r_isdst = false;
stdr.r_stdoff = 0;
stdr.r_abbrvar
= (stdabbrrp ? stdabbrrp->r_abbrvar : "");
stdrp = &stdr;
}
}
- if (stdrp == NULL && (zp->z_nrules != 0 || zp->z_stdoff != 0))
+ if (stdrp == NULL && (zp->z_nrules != 0 || zp->z_isdst))
return -1;
abbrvar = (stdrp == NULL) ? "" : stdrp->r_abbrvar;
- len = doabbr(result, zp, abbrvar, 0, true);
+ len = doabbr(result, zp, abbrvar, false, 0, true);
offsetlen = stringoffset(result + len, -zp->z_gmtoff);
if (! offsetlen) {
result[0] = '\0';
len += offsetlen;
if (dstrp == NULL)
return compat;
- len += doabbr(result + len, zp, dstrp->r_abbrvar, dstrp->r_stdoff, true);
+ len += doabbr(result + len, zp, dstrp->r_abbrvar,
+ dstrp->r_isdst, dstrp->r_stdoff, true);
if (dstrp->r_stdoff != SECSPERMIN * MINSPERHOUR) {
offsetlen = stringoffset(result + len,
-(zp->z_gmtoff + dstrp->r_stdoff));
startoff = zp->z_gmtoff;
if (zp->z_nrules == 0) {
stdoff = zp->z_stdoff;
- doabbr(startbuf, zp, NULL, stdoff, false);
+ doabbr(startbuf, zp, NULL, zp->z_isdst, stdoff, false);
type = addtype(oadd(zp->z_gmtoff, stdoff),
- startbuf, stdoff != 0, startttisstd,
+ startbuf, zp->z_isdst, startttisstd,
startttisgmt);
if (usestart) {
addtt(starttime, type);
stdoff);
doabbr(startbuf, zp,
rp->r_abbrvar,
+ rp->r_isdst,
rp->r_stdoff,
false);
continue;
doabbr(startbuf,
zp,
rp->r_abbrvar,
+ rp->r_isdst,
rp->r_stdoff,
false);
}
eats(zp->z_filename, zp->z_linenum,
rp->r_filename, rp->r_linenum);
doabbr(ab, zp, rp->r_abbrvar,
- rp->r_stdoff, false);
+ rp->r_isdst, rp->r_stdoff, false);
offset = oadd(zp->z_gmtoff, rp->r_stdoff);
- type = addtype(offset, ab, rp->r_stdoff != 0,
+ type = addtype(offset, ab, rp->r_isdst,
rp->r_todisstd, rp->r_todisgmt);
if (rp->r_hiyear == ZIC_MAX
&& ! (0 <= lastatmax
--- /dev/null
+# 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 {
+ dataform_type["vanguard"] = 1
+ dataform_type["main"] = 1
+ dataform_type["rearguard"] = 1
+
+ # The command line should set DATAFORM.
+ if (!dataform_type[DATAFORM]) exit 1
+ vanguard = DATAFORM == "vanguard"
+}
+
+/^Zone/ { zone = $2 }
+
+DATAFORM != "main" {
+ in_comment = /^#/
+ uncomment = comment_out = 0
+
+ # If the line should differ due to Czechoslovakia using negative SAVE values,
+ # uncomment the desired version and comment out the undesired one.
+ if (zone == "Europe/Prague" && /1947 Feb 23/) {
+ if (($(in_comment + 2) != "-") == vanguard) {
+ uncomment = in_comment
+ } else {
+ comment_out = !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) {
+ uncomment = in_comment
+ } else {
+ comment_out = !in_comment
+ }
+ }
+
+ # If this line should differ due to Namibia using Rule SAVE suffixes,
+ # uncomment the desired version and comment out the undesired one.
+ Rule_Namibia = /^#?Rule[\t ]+Namibia[\t ]/
+ Zone_using_Namibia_rule \
+ = (zone == "Africa/Windhoek" \
+ && ($(in_comment + 2) == "Namibia" \
+ || (1994 <= $(in_comment + 4) && $(in_comment + 4) <= 2017) \
+ || in_comment + 3 == NF))
+ if (Rule_Namibia || Zone_using_Namibia_rule) {
+ if ((Rule_Namibia \
+ ? ($(in_comment + 9) ~ /^-/ \
+ || ($(in_comment + 9) == 0 && $(in_comment + 10) == "CAT")) \
+ : $(in_comment + 1) == "2:00" && $(in_comment + 2) == "Namibia") \
+ == vanguard) {
+ uncomment = in_comment
+ } else {
+ comment_out = !in_comment
+ }
+ }
+
+ if (uncomment) {
+ sub(/^#/, "")
+ }
+ if (comment_out) {
+ 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]
+}
# 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.
print "# This zic input file is in the public domain."
}
-/^[\f\r\t\v ]*[^#\f\r\t\v ]/ {
+/^[\t ]*[^#\t ]/ {
process_input_line($0)
}
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
# of ISO 3166 2-character country codes. See the file 'iso3166.tab'.
# 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.
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
projects / platform / upstream / tzdata.git / commitdiff