Import tzdata2024a from https://github.com/JodaOrg/global-tz/releases/download/2024agtz/tzdata2024agtz.tar.gz
Summary of changes in tzdata2024a (2024-02-01 09:28:56 -0800): * Kazakhstan unifies on UTC+5. * Palestine summer time begins a week later than previously predicted in 2024 and 2025. * Historic corrections for Asia/Ho_Chi_Minh (1955) America/Toronto (1947-9) and America/Miquelon (1911).
This commit is contained in:
parent
7bab8694fc
commit
898ce95a71
|
@ -53,7 +53,7 @@ DATAFORM= main
|
|||
|
||||
LOCALTIME= Factory
|
||||
|
||||
# The POSIXRULES macro controls interpretation of POSIX-like TZ
|
||||
# The POSIXRULES macro controls interpretation of POSIX-2017.1-like TZ
|
||||
# settings like TZ='EET-2EEST' that lack DST transition rules.
|
||||
# If POSIXRULES is '-', no template is installed; this is the default.
|
||||
# Any other value for POSIXRULES is obsolete and should not be relied on, as:
|
||||
|
@ -274,7 +274,7 @@ LDLIBS=
|
|||
# -DTZ_DOMAINDIR=\"/path\" to use "/path" for gettext directory;
|
||||
# the default is system-supplied, typically "/usr/lib/locale"
|
||||
# -DTZDEFRULESTRING=\",date/time,date/time\" to default to the specified
|
||||
# DST transitions for POSIX-style TZ strings lacking them,
|
||||
# DST transitions for POSIX.1-2017-style TZ strings lacking them,
|
||||
# in the usual case where POSIXRULES is '-'. If not specified,
|
||||
# TZDEFRULESTRING defaults to US rules for future DST transitions.
|
||||
# This mishandles some past timestamps, as US DST rules have changed.
|
||||
|
@ -340,9 +340,10 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \
|
|||
# guess TM_GMTOFF from other macros; define NO_TM_GMTOFF to suppress this.
|
||||
# Similarly, if your system has a "zone abbreviation" field, define
|
||||
# -DTM_ZONE=tm_zone
|
||||
# and define NO_TM_ZONE to suppress any guessing. Although these two fields
|
||||
# not required by POSIX, a future version of POSIX is planned to require them
|
||||
# and they are widely available on GNU/Linux and BSD systems.
|
||||
# and define NO_TM_ZONE to suppress any guessing.
|
||||
# Although these two fields are not required by POSIX.1-2017,
|
||||
# POSIX 202x/D4 requires them and they are widely available
|
||||
# on GNU/Linux and BSD systems.
|
||||
#
|
||||
# The next batch of options control support for external variables
|
||||
# exported by tzcode. In practice these variables are less useful
|
||||
|
@ -352,7 +353,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \
|
|||
# # -DHAVE_TZNAME=0 # do not support "tzname"
|
||||
# # -DHAVE_TZNAME=1 # support "tzname", which is defined by system library
|
||||
# # -DHAVE_TZNAME=2 # support and define "tzname"
|
||||
# # to the "CFLAGS=" line. "tzname" is required by POSIX 1988 and later.
|
||||
# # to the "CFLAGS=" line. "tzname" is required by POSIX.1-1988 and later.
|
||||
# # If not defined, the code attempts to guess HAVE_TZNAME from other macros.
|
||||
# # Warning: unless time_tz is also defined, HAVE_TZNAME=1 can cause
|
||||
# # crashes when combined with some platforms' standard libraries,
|
||||
|
@ -362,8 +363,8 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \
|
|||
# # -DUSG_COMPAT=0 # do not support
|
||||
# # -DUSG_COMPAT=1 # support, and variables are defined by system library
|
||||
# # -DUSG_COMPAT=2 # support and define variables
|
||||
# # to the "CFLAGS=" line; "timezone" and "daylight" are inspired by
|
||||
# # Unix Systems Group code and are required by POSIX 2008 (with XSI) and later.
|
||||
# # to the "CFLAGS=" line; "timezone" and "daylight" are inspired by Unix
|
||||
# # Systems Group code and are required by POSIX.1-2008 and later (with XSI).
|
||||
# # If not defined, the code attempts to guess USG_COMPAT from other macros.
|
||||
# #
|
||||
# # To support the external variable "altzone", add
|
||||
|
@ -427,7 +428,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \
|
|||
|
||||
# The name of a POSIX-like library archiver, its flags, C compiler,
|
||||
# linker flags, and 'make' utility. Ordinarily the defaults suffice.
|
||||
# The commented-out values are the defaults specified by POSIX 202x/D3.
|
||||
# The commented-out values are the defaults specified by POSIX.1-202x/D4.
|
||||
#AR = ar
|
||||
#ARFLAGS = -rv
|
||||
#CC = c17
|
||||
|
@ -439,6 +440,12 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \
|
|||
|
||||
LEAPSECONDS=
|
||||
|
||||
# Where to fetch leap-seconds.list from.
|
||||
leaplist_URI = \
|
||||
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
|
||||
# The file is generated by the IERS Earth Orientation Centre, in Paris.
|
||||
leaplist_TZ = Europe/Paris
|
||||
|
||||
# The zic command and its arguments.
|
||||
|
||||
zic= ./zic
|
||||
|
@ -471,7 +478,8 @@ AWK= awk
|
|||
# is typically nicer if it works.
|
||||
KSHELL= /bin/bash
|
||||
|
||||
# Name of curl <https://curl.haxx.se/>, used for HTML validation.
|
||||
# Name of curl <https://curl.haxx.se/>, used for HTML validation
|
||||
# and to fetch leap-seconds.list from upstream.
|
||||
CURL= curl
|
||||
|
||||
# Name of GNU Privacy Guard <https://gnupg.org/>, used to sign distributions.
|
||||
|
@ -718,6 +726,28 @@ leapseconds: $(LEAP_DEPS)
|
|||
-f leapseconds.awk leap-seconds.list >$@.out
|
||||
mv $@.out $@
|
||||
|
||||
# Awk script to extract a Git-style author from leap-seconds.list comments.
|
||||
EXTRACT_AUTHOR = \
|
||||
author_line { sub(/^.[[:space:]]*/, ""); \
|
||||
sub(/:[[:space:]]*/, " <"); \
|
||||
printf "%s>\n", $$0; \
|
||||
success = 1; \
|
||||
exit \
|
||||
} \
|
||||
/Questions or comments to:/ { author_line = 1 } \
|
||||
END { exit !success }
|
||||
|
||||
# Fetch leap-seconds.list from upstream.
|
||||
fetch-leap-seconds.list:
|
||||
$(CURL) -OR $(leaplist_URI)
|
||||
|
||||
# Fetch leap-seconds.list from upstream and commit it to the local repository.
|
||||
commit-leap-seconds.list: fetch-leap-seconds.list
|
||||
author=$$($(AWK) '$(EXTRACT_AUTHOR)' leap-seconds.list) && \
|
||||
date=$$(TZ=$(leaplist_TZ) stat -c%y leap-seconds.list) && \
|
||||
git commit --author="$$author" --date="$$date" -m'make $@' \
|
||||
leap-seconds.list
|
||||
|
||||
# Arguments to pass to submakes of install_data.
|
||||
# They can be overridden by later submake arguments.
|
||||
INSTALLARGS = \
|
||||
|
@ -1314,7 +1344,8 @@ zic.o: private.h tzfile.h tzdir.h version.h
|
|||
.PHONY: ALL INSTALL all
|
||||
.PHONY: check check_mild check_time_t_alternatives
|
||||
.PHONY: check_web check_zishrink
|
||||
.PHONY: clean clean_misc dummy.zd force_tzs
|
||||
.PHONY: clean clean_misc commit-leap-seconds.list dummy.zd
|
||||
.PHONY: fetch-leap-seconds.list force_tzs
|
||||
.PHONY: install install_data maintainer-clean names
|
||||
.PHONY: posix_only posix_right public
|
||||
.PHONY: rearguard_signatures rearguard_signatures_version
|
||||
|
|
|
@ -1,5 +1,73 @@
|
|||
News for the tz database
|
||||
|
||||
Release 2024a - 2024-02-01 09:28:56 -0800
|
||||
|
||||
Briefly:
|
||||
Kazakhstan unifies on UTC+5 beginning 2024-03-01.
|
||||
Palestine springs forward a week later after Ramadan.
|
||||
zic no longer pretends to support indefinite-past DST.
|
||||
localtime no longer mishandles Ciudad Juárez in 2422.
|
||||
|
||||
Changes to future timestamps
|
||||
|
||||
Kazakhstan unifies on UTC+5. This affects Asia/Almaty and
|
||||
Asia/Qostanay which together represent the eastern portion of the
|
||||
country that will transition from UTC+6 on 2024-03-01 at 00:00 to
|
||||
join the western portion. (Thanks to Zhanbolat Raimbekov.)
|
||||
|
||||
Palestine springs forward a week later than previously predicted
|
||||
in 2024 and 2025. (Thanks to Heba Hamad.) Change spring-forward
|
||||
predictions to the second Saturday after Ramadan, not the first;
|
||||
this also affects other predictions starting in 2039.
|
||||
|
||||
Changes to past timestamps
|
||||
|
||||
Asia/Ho_Chi_Minh's 1955-07-01 transition occurred at 01:00
|
||||
not 00:00. (Thanks to Đoàn Trần Công Danh.)
|
||||
|
||||
From 1947 through 1949, Toronto's transitions occurred at 02:00
|
||||
not 00:00. (Thanks to Chris Walton.)
|
||||
|
||||
In 1911 Miquelon adopted standard time on June 15, not May 15.
|
||||
|
||||
Changes to code
|
||||
|
||||
The FROM and TO columns of Rule lines can no longer be "minimum"
|
||||
or an abbreviation of "minimum", because TZif files do not support
|
||||
DST rules that extend into the indefinite past - although these
|
||||
rules were supported when TZif files had only 32-bit data, this
|
||||
stopped working when 64-bit TZif files were introduced in 1995.
|
||||
This should not be a problem for realistic data, since DST was
|
||||
first used in the 20th century. As a transition aid, FROM columns
|
||||
like "minimum" are now diagnosed and then treated as if they were
|
||||
the year 1900; this should suffice for TZif files on old systems
|
||||
with only 32-bit time_t, and it is more compatible with bugs in
|
||||
2023c-and-earlier localtime.c. (Problem reported by Yoshito
|
||||
Umaoka.)
|
||||
|
||||
localtime and related functions no longer mishandle some
|
||||
timestamps that occur about 400 years after a switch to a time
|
||||
zone with a DST schedule. In 2023d data this problem was visible
|
||||
for some timestamps in November 2422, November 2822, etc. in
|
||||
America/Ciudad_Juarez. (Problem reported by Gilmore Davidson.)
|
||||
|
||||
strftime %s now uses tm_gmtoff if available. (Problem and draft
|
||||
patch reported by Dag-Erling Smørgrav.)
|
||||
|
||||
Changes to build procedure
|
||||
|
||||
The leap-seconds.list file is now copied from the IERS instead of
|
||||
from its downstream counterpart at NIST, as the IERS version is
|
||||
now in the public domain too and tends to be more up-to-date.
|
||||
(Thanks to Martin Burnicki for liaisoning with the IERS.)
|
||||
|
||||
Changes to documentation
|
||||
|
||||
The strftime man page documents which struct tm members affect
|
||||
which conversion specs, and that tzset is called. (Problems
|
||||
reported by Robert Elz and Steve Summit.)
|
||||
|
||||
|
||||
Release 2023d - 2023-12-21 20:02:24 -0800
|
||||
|
||||
Briefly:
|
||||
|
|
|
@ -30,6 +30,10 @@
|
|||
# Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94.
|
||||
# https://www.jstor.org/stable/1774359
|
||||
#
|
||||
# For the 1911/1912 establishment of standard time in French possessions, see:
|
||||
# Société Française de Physique, Recueil de constantes physiques (1913),
|
||||
# page 752, 18b.
|
||||
#
|
||||
# European-style abbreviations are commonly used along the Mediterranean.
|
||||
# For sub-Saharan Africa abbreviations were less standardized.
|
||||
# Previous editions of this database used WAT, CAT, SAT, and EAT
|
||||
|
@ -153,7 +157,7 @@ Zone Africa/Bangui 1:14:20 - LMT 1912
|
|||
|
||||
# Chad
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
Zone Africa/Ndjamena 1:00:12 - LMT 1912 # N'Djamena
|
||||
Zone Africa/Ndjamena 1:00:12 - LMT 1912 Jan 1 # N'Djamena
|
||||
1:00 - WAT 1979 Oct 14
|
||||
1:00 1:00 WAST 1980 Mar 8
|
||||
1:00 - WAT
|
||||
|
@ -188,7 +192,7 @@ Zone Africa/Brazzaville 1:01:08 - LMT 1912
|
|||
# Inaccessible, Nightingale: uninhabited
|
||||
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
Zone Africa/Abidjan -0:16:08 - LMT 1912
|
||||
Zone Africa/Abidjan -0:16:08 - LMT 1912 Jan 1
|
||||
0:00 - GMT
|
||||
|
||||
# Djibouti
|
||||
|
|
|
@ -2478,18 +2478,33 @@ Zone Asia/Amman 2:23:44 - LMT 1931
|
|||
# effective December 21st, 2018....
|
||||
# http://adilet.zan.kz/rus/docs/P1800000817 (russian language).
|
||||
|
||||
# From Zhanbolat Raimbekov (2024-01-19):
|
||||
# Kazakhstan (all parts) switching to UTC+5 on March 1, 2024
|
||||
# https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru
|
||||
# [in Russian]
|
||||
# (2024-01-20): https://primeminister.kz/ru/decisions/19012024-20
|
||||
#
|
||||
# From Alexander Krivenyshev (2024-01-19):
|
||||
# According to a different news and the official web site for the Ministry of
|
||||
# Trade and Integration of the Republic of Kazakhstan:
|
||||
# https://en.inform.kz/news/kazakhstan-to-switch-to-single-hour-zone-mar-1-54ad0b/
|
||||
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
#
|
||||
# Almaty (formerly Alma-Ata), representing most locations in Kazakhstan
|
||||
# This includes KZ-AKM, KZ-ALA, KZ-ALM, KZ-AST, KZ-BAY, KZ-VOS, KZ-ZHA,
|
||||
# KZ-KAR, KZ-SEV, KZ-PAV, and KZ-YUZ.
|
||||
# This includes Abai/Abay (ISO 3166-2 code KZ-10), Aqmola/Akmola (KZ-11),
|
||||
# Almaty (KZ-19), Almaty city (KZ-75), Astana city (KZ-71),
|
||||
# East Kazkhstan (KZ-63), Jambyl/Zhambyl (KZ-31), Jetisu/Zhetysu (KZ-33),
|
||||
# Karaganda (KZ-35), North Kazakhstan (KZ-59), Pavlodar (KZ-55),
|
||||
# Shyumkent city (KZ-79), Turkistan (KZ-61), and Ulytau (KZ-62).
|
||||
Zone Asia/Almaty 5:07:48 - LMT 1924 May 2 # or Alma-Ata
|
||||
5:00 - +05 1930 Jun 21
|
||||
6:00 RussiaAsia +06/+07 1991 Mar 31 2:00s
|
||||
5:00 RussiaAsia +05/+06 1992 Jan 19 2:00s
|
||||
6:00 RussiaAsia +06/+07 2004 Oct 31 2:00s
|
||||
6:00 - +06
|
||||
# Qyzylorda (aka Kyzylorda, Kizilorda, Kzyl-Orda, etc.) (KZ-KZY)
|
||||
6:00 - +06 2024 Mar 1 0:00
|
||||
5:00 - +05
|
||||
# Qyzylorda (aka Kyzylorda, Kizilorda, Kzyl-Orda, etc.) (KZ-43)
|
||||
Zone Asia/Qyzylorda 4:21:52 - LMT 1924 May 2
|
||||
4:00 - +04 1930 Jun 21
|
||||
5:00 - +05 1981 Apr 1
|
||||
|
@ -2502,8 +2517,7 @@ Zone Asia/Qyzylorda 4:21:52 - LMT 1924 May 2
|
|||
5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s
|
||||
6:00 - +06 2018 Dec 21 0:00
|
||||
5:00 - +05
|
||||
#
|
||||
# Qostanay (aka Kostanay, Kustanay) (KZ-KUS)
|
||||
# Qostanay (aka Kostanay, Kustanay) (KZ-39)
|
||||
# The 1991/2 rules are unclear partly because of the 1997 Turgai
|
||||
# reorganization.
|
||||
Zone Asia/Qostanay 4:14:28 - LMT 1924 May 2
|
||||
|
@ -2514,9 +2528,9 @@ Zone Asia/Qostanay 4:14:28 - LMT 1924 May 2
|
|||
5:00 RussiaAsia +05/+06 1991 Mar 31 2:00s
|
||||
4:00 RussiaAsia +04/+05 1992 Jan 19 2:00s
|
||||
5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s
|
||||
6:00 - +06
|
||||
|
||||
# Aqtöbe (aka Aktobe, formerly Aktyubinsk) (KZ-AKT)
|
||||
6:00 - +06 2024 Mar 1 0:00
|
||||
5:00 - +05
|
||||
# Aqtöbe (aka Aktobe, formerly Aktyubinsk) (KZ-15)
|
||||
Zone Asia/Aqtobe 3:48:40 - LMT 1924 May 2
|
||||
4:00 - +04 1930 Jun 21
|
||||
5:00 - +05 1981 Apr 1
|
||||
|
@ -2526,7 +2540,7 @@ Zone Asia/Aqtobe 3:48:40 - LMT 1924 May 2
|
|||
4:00 RussiaAsia +04/+05 1992 Jan 19 2:00s
|
||||
5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s
|
||||
5:00 - +05
|
||||
# Mangghystaū (KZ-MAN)
|
||||
# Mangghystaū (KZ-47)
|
||||
# Aqtau was not founded until 1963, but it represents an inhabited region,
|
||||
# so include timestamps before 1963.
|
||||
Zone Asia/Aqtau 3:21:04 - LMT 1924 May 2
|
||||
|
@ -2538,7 +2552,7 @@ Zone Asia/Aqtau 3:21:04 - LMT 1924 May 2
|
|||
5:00 RussiaAsia +05/+06 1994 Sep 25 2:00s
|
||||
4:00 RussiaAsia +04/+05 2004 Oct 31 2:00s
|
||||
5:00 - +05
|
||||
# Atyraū (KZ-ATY) is like Mangghystaū except it switched from
|
||||
# Atyraū (KZ-23) is like Mangghystaū except it switched from
|
||||
# +04/+05 to +05/+06 in spring 1999, not fall 1994.
|
||||
Zone Asia/Atyrau 3:27:44 - LMT 1924 May 2
|
||||
3:00 - +03 1930 Jun 21
|
||||
|
@ -2549,7 +2563,7 @@ Zone Asia/Atyrau 3:27:44 - LMT 1924 May 2
|
|||
5:00 RussiaAsia +05/+06 1999 Mar 28 2:00s
|
||||
4:00 RussiaAsia +04/+05 2004 Oct 31 2:00s
|
||||
5:00 - +05
|
||||
# West Kazakhstan (KZ-ZAP)
|
||||
# West Kazakhstan (KZ-27)
|
||||
# From Paul Eggert (2016-03-18):
|
||||
# The 1989 transition is from USSR act No. 227 (1989-03-14).
|
||||
Zone Asia/Oral 3:25:24 - LMT 1924 May 2 # or Ural'sk
|
||||
|
@ -3480,19 +3494,26 @@ Zone Asia/Karachi 4:28:12 - LMT 1907
|
|||
# ... winter time will begin in Palestine from Saturday 10-28-2023,
|
||||
# 02:00 AM by 60 minutes back.
|
||||
#
|
||||
# From Paul Eggert (2023-03-22):
|
||||
# From Heba Hamad (2024-01-25):
|
||||
# the summer time for the years 2024,2025 will begin in Palestine
|
||||
# from Saturday at 02:00 AM by 60 minutes forward as shown below:
|
||||
# year date
|
||||
# 2024 2024-04-20
|
||||
# 2025 2025-04-12
|
||||
#
|
||||
# From Paul Eggert (2024-01-25):
|
||||
# For now, guess that spring and fall transitions will normally
|
||||
# continue to use 2022's rules, that during DST Palestine will switch
|
||||
# to standard time at 02:00 the last Saturday before Ramadan and back
|
||||
# to DST at 02:00 the first Saturday after Ramadan, and that
|
||||
# to DST at 02:00 the second Saturday after Ramadan, and that
|
||||
# if the normal spring-forward or fall-back transition occurs during
|
||||
# Ramadan the former is delayed and the latter advanced.
|
||||
# To implement this, I predicted Ramadan-oriented transition dates for
|
||||
# 2023 through 2086 by running the following program under GNU Emacs 28.2,
|
||||
# 2026 through 2086 by running the following program under GNU Emacs 29.2,
|
||||
# with the results integrated by hand into the table below.
|
||||
# Predictions after 2086 are approximated without Ramadan.
|
||||
#
|
||||
# (let ((islamic-year 1444))
|
||||
# (let ((islamic-year 1447))
|
||||
# (require 'cal-islam)
|
||||
# (while (< islamic-year 1510)
|
||||
# (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year)))
|
||||
|
@ -3501,6 +3522,7 @@ Zone Asia/Karachi 4:28:12 - LMT 1907
|
|||
# (while (/= saturday (mod (setq a (1- a)) 7)))
|
||||
# (while (/= saturday (mod b 7))
|
||||
# (setq b (1+ b)))
|
||||
# (setq b (+ 7 b))
|
||||
# (setq a (calendar-gregorian-from-absolute a))
|
||||
# (setq b (calendar-gregorian-from-absolute b))
|
||||
# (insert
|
||||
|
@ -3551,84 +3573,84 @@ Rule Palestine 2021 only - Oct 29 1:00 0 -
|
|||
Rule Palestine 2022 only - Mar 27 0:00 1:00 S
|
||||
Rule Palestine 2022 2035 - Oct Sat<=30 2:00 0 -
|
||||
Rule Palestine 2023 only - Apr 29 2:00 1:00 S
|
||||
Rule Palestine 2024 only - Apr 13 2:00 1:00 S
|
||||
Rule Palestine 2025 only - Apr 5 2:00 1:00 S
|
||||
Rule Palestine 2024 only - Apr 20 2:00 1:00 S
|
||||
Rule Palestine 2025 only - Apr 12 2:00 1:00 S
|
||||
Rule Palestine 2026 2054 - Mar Sat<=30 2:00 1:00 S
|
||||
Rule Palestine 2036 only - Oct 18 2:00 0 -
|
||||
Rule Palestine 2037 only - Oct 10 2:00 0 -
|
||||
Rule Palestine 2038 only - Sep 25 2:00 0 -
|
||||
Rule Palestine 2039 only - Sep 17 2:00 0 -
|
||||
Rule Palestine 2039 only - Oct 22 2:00 1:00 S
|
||||
Rule Palestine 2039 2067 - Oct Sat<=30 2:00 0 -
|
||||
Rule Palestine 2040 only - Sep 1 2:00 0 -
|
||||
Rule Palestine 2040 only - Oct 13 2:00 1:00 S
|
||||
Rule Palestine 2040 only - Oct 20 2:00 1:00 S
|
||||
Rule Palestine 2040 2067 - Oct Sat<=30 2:00 0 -
|
||||
Rule Palestine 2041 only - Aug 24 2:00 0 -
|
||||
Rule Palestine 2041 only - Sep 28 2:00 1:00 S
|
||||
Rule Palestine 2041 only - Oct 5 2:00 1:00 S
|
||||
Rule Palestine 2042 only - Aug 16 2:00 0 -
|
||||
Rule Palestine 2042 only - Sep 20 2:00 1:00 S
|
||||
Rule Palestine 2042 only - Sep 27 2:00 1:00 S
|
||||
Rule Palestine 2043 only - Aug 1 2:00 0 -
|
||||
Rule Palestine 2043 only - Sep 12 2:00 1:00 S
|
||||
Rule Palestine 2043 only - Sep 19 2:00 1:00 S
|
||||
Rule Palestine 2044 only - Jul 23 2:00 0 -
|
||||
Rule Palestine 2044 only - Aug 27 2:00 1:00 S
|
||||
Rule Palestine 2044 only - Sep 3 2:00 1:00 S
|
||||
Rule Palestine 2045 only - Jul 15 2:00 0 -
|
||||
Rule Palestine 2045 only - Aug 19 2:00 1:00 S
|
||||
Rule Palestine 2045 only - Aug 26 2:00 1:00 S
|
||||
Rule Palestine 2046 only - Jun 30 2:00 0 -
|
||||
Rule Palestine 2046 only - Aug 11 2:00 1:00 S
|
||||
Rule Palestine 2046 only - Aug 18 2:00 1:00 S
|
||||
Rule Palestine 2047 only - Jun 22 2:00 0 -
|
||||
Rule Palestine 2047 only - Jul 27 2:00 1:00 S
|
||||
Rule Palestine 2047 only - Aug 3 2:00 1:00 S
|
||||
Rule Palestine 2048 only - Jun 6 2:00 0 -
|
||||
Rule Palestine 2048 only - Jul 18 2:00 1:00 S
|
||||
Rule Palestine 2048 only - Jul 25 2:00 1:00 S
|
||||
Rule Palestine 2049 only - May 29 2:00 0 -
|
||||
Rule Palestine 2049 only - Jul 3 2:00 1:00 S
|
||||
Rule Palestine 2049 only - Jul 10 2:00 1:00 S
|
||||
Rule Palestine 2050 only - May 21 2:00 0 -
|
||||
Rule Palestine 2050 only - Jun 25 2:00 1:00 S
|
||||
Rule Palestine 2050 only - Jul 2 2:00 1:00 S
|
||||
Rule Palestine 2051 only - May 6 2:00 0 -
|
||||
Rule Palestine 2051 only - Jun 17 2:00 1:00 S
|
||||
Rule Palestine 2051 only - Jun 24 2:00 1:00 S
|
||||
Rule Palestine 2052 only - Apr 27 2:00 0 -
|
||||
Rule Palestine 2052 only - Jun 1 2:00 1:00 S
|
||||
Rule Palestine 2052 only - Jun 8 2:00 1:00 S
|
||||
Rule Palestine 2053 only - Apr 12 2:00 0 -
|
||||
Rule Palestine 2053 only - May 24 2:00 1:00 S
|
||||
Rule Palestine 2053 only - May 31 2:00 1:00 S
|
||||
Rule Palestine 2054 only - Apr 4 2:00 0 -
|
||||
Rule Palestine 2054 only - May 16 2:00 1:00 S
|
||||
Rule Palestine 2055 only - May 1 2:00 1:00 S
|
||||
Rule Palestine 2056 only - Apr 22 2:00 1:00 S
|
||||
Rule Palestine 2057 only - Apr 7 2:00 1:00 S
|
||||
Rule Palestine 2058 max - Mar Sat<=30 2:00 1:00 S
|
||||
Rule Palestine 2054 only - May 23 2:00 1:00 S
|
||||
Rule Palestine 2055 only - May 8 2:00 1:00 S
|
||||
Rule Palestine 2056 only - Apr 29 2:00 1:00 S
|
||||
Rule Palestine 2057 only - Apr 14 2:00 1:00 S
|
||||
Rule Palestine 2058 only - Apr 6 2:00 1:00 S
|
||||
Rule Palestine 2059 max - Mar Sat<=30 2:00 1:00 S
|
||||
Rule Palestine 2068 only - Oct 20 2:00 0 -
|
||||
Rule Palestine 2069 only - Oct 12 2:00 0 -
|
||||
Rule Palestine 2070 only - Oct 4 2:00 0 -
|
||||
Rule Palestine 2071 only - Sep 19 2:00 0 -
|
||||
Rule Palestine 2072 only - Sep 10 2:00 0 -
|
||||
Rule Palestine 2072 only - Oct 15 2:00 1:00 S
|
||||
Rule Palestine 2072 only - Oct 22 2:00 1:00 S
|
||||
Rule Palestine 2072 max - Oct Sat<=30 2:00 0 -
|
||||
Rule Palestine 2073 only - Sep 2 2:00 0 -
|
||||
Rule Palestine 2073 only - Oct 7 2:00 1:00 S
|
||||
Rule Palestine 2073 only - Oct 14 2:00 1:00 S
|
||||
Rule Palestine 2074 only - Aug 18 2:00 0 -
|
||||
Rule Palestine 2074 only - Sep 29 2:00 1:00 S
|
||||
Rule Palestine 2074 only - Oct 6 2:00 1:00 S
|
||||
Rule Palestine 2075 only - Aug 10 2:00 0 -
|
||||
Rule Palestine 2075 only - Sep 14 2:00 1:00 S
|
||||
Rule Palestine 2075 only - Sep 21 2:00 1:00 S
|
||||
Rule Palestine 2076 only - Jul 25 2:00 0 -
|
||||
Rule Palestine 2076 only - Sep 5 2:00 1:00 S
|
||||
Rule Palestine 2076 only - Sep 12 2:00 1:00 S
|
||||
Rule Palestine 2077 only - Jul 17 2:00 0 -
|
||||
Rule Palestine 2077 only - Aug 28 2:00 1:00 S
|
||||
Rule Palestine 2077 only - Sep 4 2:00 1:00 S
|
||||
Rule Palestine 2078 only - Jul 9 2:00 0 -
|
||||
Rule Palestine 2078 only - Aug 13 2:00 1:00 S
|
||||
Rule Palestine 2078 only - Aug 20 2:00 1:00 S
|
||||
Rule Palestine 2079 only - Jun 24 2:00 0 -
|
||||
Rule Palestine 2079 only - Aug 5 2:00 1:00 S
|
||||
Rule Palestine 2079 only - Aug 12 2:00 1:00 S
|
||||
Rule Palestine 2080 only - Jun 15 2:00 0 -
|
||||
Rule Palestine 2080 only - Jul 20 2:00 1:00 S
|
||||
Rule Palestine 2080 only - Jul 27 2:00 1:00 S
|
||||
Rule Palestine 2081 only - Jun 7 2:00 0 -
|
||||
Rule Palestine 2081 only - Jul 12 2:00 1:00 S
|
||||
Rule Palestine 2081 only - Jul 19 2:00 1:00 S
|
||||
Rule Palestine 2082 only - May 23 2:00 0 -
|
||||
Rule Palestine 2082 only - Jul 4 2:00 1:00 S
|
||||
Rule Palestine 2082 only - Jul 11 2:00 1:00 S
|
||||
Rule Palestine 2083 only - May 15 2:00 0 -
|
||||
Rule Palestine 2083 only - Jun 19 2:00 1:00 S
|
||||
Rule Palestine 2083 only - Jun 26 2:00 1:00 S
|
||||
Rule Palestine 2084 only - Apr 29 2:00 0 -
|
||||
Rule Palestine 2084 only - Jun 10 2:00 1:00 S
|
||||
Rule Palestine 2084 only - Jun 17 2:00 1:00 S
|
||||
Rule Palestine 2085 only - Apr 21 2:00 0 -
|
||||
Rule Palestine 2085 only - Jun 2 2:00 1:00 S
|
||||
Rule Palestine 2085 only - Jun 9 2:00 1:00 S
|
||||
Rule Palestine 2086 only - Apr 13 2:00 0 -
|
||||
Rule Palestine 2086 only - May 18 2:00 1:00 S
|
||||
Rule Palestine 2086 only - May 25 2:00 1:00 S
|
||||
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
Zone Asia/Gaza 2:17:52 - LMT 1900 Oct
|
||||
|
@ -3656,7 +3678,7 @@ Zone Asia/Hebron 2:20:23 - LMT 1900 Oct
|
|||
|
||||
# Philippines
|
||||
|
||||
# From Paul Eggert (2018-11-18):
|
||||
# From Paul Eggert (2024-01-21):
|
||||
# The Spanish initially used American (west-of-Greenwich) time.
|
||||
# It is unknown what time Manila kept when the British occupied it from
|
||||
# 1762-10-06 through 1764-04; for now assume it kept American time.
|
||||
|
@ -3664,7 +3686,7 @@ Zone Asia/Hebron 2:20:23 - LMT 1900 Oct
|
|||
# Philippines, issued a proclamation announcing that 1844-12-30 was to
|
||||
# be immediately followed by 1845-01-01; see R.H. van Gent's
|
||||
# History of the International Date Line
|
||||
# https://www.staff.science.uu.nl/~gent0113/idl/idl_philippines.htm
|
||||
# https://webspace.science.uu.nl/~gent0113/idl/idl_philippines.htm
|
||||
# The rest of the data entries are from Shanks & Pottenger.
|
||||
|
||||
# From Jesper Nørgaard Welen (2006-04-26):
|
||||
|
@ -4081,7 +4103,8 @@ Zone Asia/Tashkent 4:37:11 - LMT 1924 May 2
|
|||
# The English-language name of Vietnam's most populous city is "Ho Chi Minh
|
||||
# City"; use Ho_Chi_Minh below to avoid a name of more than 14 characters.
|
||||
|
||||
# From Paul Eggert (2022-07-27) after a 2014 heads-up from Trần Ngọc Quân:
|
||||
# From Paul Eggert (2024-01-14) after a 2014 heads-up from Trần Ngọc Quân
|
||||
# and a 2024-01-14 heads-up from Đoàn Trần Công Danh:
|
||||
# Trần Tiến Bình's authoritative book "Lịch Việt Nam: thế kỷ XX-XXI (1901-2100)"
|
||||
# (Nhà xuất bản Văn Hoá - Thông Tin, Hanoi, 2005), pp 49-50,
|
||||
# is quoted verbatim in:
|
||||
|
@ -4111,14 +4134,35 @@ Zone Asia/Tashkent 4:37:11 - LMT 1924 May 2
|
|||
#
|
||||
# Trần cites the following sources; it's unclear which supplied the info above.
|
||||
#
|
||||
# Hoàng Xuân Hãn: "Lịch và lịch Việt Nam". Tập san Khoa học Xã hội,
|
||||
# No. 9, Paris, February 1982.
|
||||
# Hoàng Xuân Hãn: "Lịch và lịch Việt Nam". Tập san Khoa học Xã hội,
|
||||
# No. 9, Paris, February 1982.
|
||||
#
|
||||
# Lê Thành Lân: "Lịch và niên biểu lịch sử hai mươi thế kỷ (0001-2010)",
|
||||
# NXB Thống kê, Hanoi, 2000.
|
||||
# Lê Thành Lân: "Lịch và niên biểu lịch sử hai mươi thế kỷ (0001-2010)",
|
||||
# NXB Thống kê, Hanoi, 2000.
|
||||
#
|
||||
# Lê Thành Lân: "Lịch hai thế kỷ (1802-2010) và các lịch vĩnh cửu",
|
||||
# NXB Thuận Hoá, Huế, 1995.
|
||||
# Lê Thành Lân: "Lịch hai thế kỷ (1802-2010) và các lịch vĩnh cửu",
|
||||
# NXB Thuận Hoá, Huế, 1995.
|
||||
#
|
||||
# Here is the decision for the September 1945 transition:
|
||||
# Võ Nguyên Giáp, Việt Nam Dân Quốc Công Báo, No. 1 (1945-09-29), page 13
|
||||
# http://baochi.nlv.gov.vn/baochi/cgi-bin/baochi?a=d&d=JwvzO19450929.2.5&dliv=none
|
||||
# It says that on 1945-09-01 at 24:00, Vietnam moved back two hours, to +07.
|
||||
# It also mentions a 1945-03-29 decree (by a Japanese Goveror-General)
|
||||
# to set the time zone to +09, but does not say whether that decree
|
||||
# merely legalized an earlier change to +09.
|
||||
#
|
||||
# July 1955 transition:
|
||||
# Ngô Đình Diệm, Công Báo Việt Nam, No. 92 (1955-07-02), page 1780-1781
|
||||
# Ordinance (Dụ) No. 46 (1955-06-25)
|
||||
# http://ddsnext.crl.edu/titles/32341#?c=0&m=29&s=0&cv=4&r=0&xywh=-89%2C342%2C1724%2C1216
|
||||
# It says that on 1955-07-01 at 01:00, South Vietnam moved back 1 hour (to +07).
|
||||
#
|
||||
# December 1959 transition:
|
||||
# Ngô Đình Diệm, Công Báo Việt Nam Cộng Hòa, 1960 part 1 (1960-01-02), page 62
|
||||
# Decree (Sắc lệnh) No. 362-TTP (1959-12-30)
|
||||
# http://ddsnext.crl.edu/titles/32341#?c=0&m=138&s=0&cv=793&r=0&xywh=-54%2C1504%2C1705%2C1202
|
||||
# It says that on 1959-12-31 at 23:00, South Vietnam moved forward 1 hour (to +08).
|
||||
|
||||
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
#STDOFF 7:06:30.13
|
||||
|
@ -4126,9 +4170,9 @@ Zone Asia/Ho_Chi_Minh 7:06:30 - LMT 1906 Jul 1
|
|||
7:06:30 - PLMT 1911 May 1 # Phù Liễn MT
|
||||
7:00 - +07 1942 Dec 31 23:00
|
||||
8:00 - +08 1945 Mar 14 23:00
|
||||
9:00 - +09 1945 Sep 2
|
||||
9:00 - +09 1945 Sep 1 24:00
|
||||
7:00 - +07 1947 Apr 1
|
||||
8:00 - +08 1955 Jul 1
|
||||
8:00 - +08 1955 Jul 1 01:00
|
||||
7:00 - +07 1959 Dec 31 23:00
|
||||
8:00 - +08 1975 Jun 13
|
||||
7:00 - +07
|
||||
|
|
|
@ -430,11 +430,11 @@ Zone Pacific/Fiji 11:55:44 - LMT 1915 Oct 26 # Suva
|
|||
|
||||
# French Polynesia
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
Zone Pacific/Gambier -8:59:48 - LMT 1912 Oct # Rikitea
|
||||
Zone Pacific/Gambier -8:59:48 - LMT 1912 Oct 1 # Rikitea
|
||||
-9:00 - -09
|
||||
Zone Pacific/Marquesas -9:18:00 - LMT 1912 Oct
|
||||
Zone Pacific/Marquesas -9:18:00 - LMT 1912 Oct 1
|
||||
-9:30 - -0930
|
||||
Zone Pacific/Tahiti -9:58:16 - LMT 1912 Oct # Papeete
|
||||
Zone Pacific/Tahiti -9:58:16 - LMT 1912 Oct 1 # Papeete
|
||||
-10:00 - -10
|
||||
# Clipperton (near North America) is administered from French Polynesia;
|
||||
# it is uninhabited.
|
||||
|
@ -843,7 +843,7 @@ Zone Pacific/Apia 12:33:04 - LMT 1892 Jul 5
|
|||
# Solomon Is
|
||||
# excludes Bougainville, for which see Papua New Guinea
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct # Honiara
|
||||
Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct 1 # Honiara
|
||||
11:00 - +11
|
||||
|
||||
# Tokelau
|
||||
|
@ -1025,6 +1025,10 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901
|
|||
# Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94.
|
||||
# https://www.jstor.org/stable/1774359
|
||||
#
|
||||
# For the 1911/1912 establishment of standard time in French possessions, see:
|
||||
# Société Française de Physique, Recueil de constantes physiques (1913),
|
||||
# page 752, 18b.
|
||||
#
|
||||
# A reliable and entertaining source about time zones is
|
||||
# Derek Howse, Greenwich time and longitude, Philip Wilson Publishers (1997).
|
||||
#
|
||||
|
@ -2101,7 +2105,7 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901
|
|||
# ordaining - by a masterpiece of diplomatic flattery - that
|
||||
# the Fourth of July should be celebrated twice in that year."
|
||||
# This happened in 1892, according to the Evening News (Sydney) of 1892-07-20.
|
||||
# https://www.staff.science.uu.nl/~gent0113/idl/idl.htm
|
||||
# https://webspace.science.uu.nl/~gent0113/idl/idl_alaska_samoa.htm
|
||||
|
||||
# Although Shanks & Pottenger says they both switched to UT -11:30
|
||||
# in 1911, and to -11 in 1950. many earlier sources give -11
|
||||
|
|
|
@ -45,7 +45,7 @@ END {
|
|||
for (zone in zone_data) {
|
||||
data = zone_data[zone]
|
||||
if (!zonenow[data]) {
|
||||
printf "checknow.tab should have one of:%s\n", zones[data]
|
||||
printf "zonenow.tab should have one of:%s\n", zones[data]
|
||||
zonenow[data] = zone # This suppresses duplicate diagnostics.
|
||||
status = 1
|
||||
}
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
# These entries are for uses not otherwise covered by the tz database.
|
||||
# Their main practical use is for platforms like Android that lack
|
||||
# support for POSIX-style TZ strings. On such platforms these entries
|
||||
# support for POSIX.1-2017-style TZ strings. On such platforms these entries
|
||||
# can be useful if the timezone database is wrong or if a ship or
|
||||
# aircraft at sea is not in a timezone.
|
||||
|
||||
|
|
|
@ -1028,9 +1028,34 @@ Zone Europe/Zagreb 1:03:52 - LMT 1884
|
|||
|
||||
# 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.
|
||||
# From Ivan Benovic (2024-01-30):
|
||||
# https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/1946/54/
|
||||
# (This is an official link to the Czechoslovak Summer Time Act of
|
||||
# March 8, 1946 that authorizes the Czechoslovak government to set the
|
||||
# exact dates of change to summer time and back to Central European Time.
|
||||
# The act also implicitly confirms Central European Time as the
|
||||
# official time zone of Czechoslovakia and currently remains in force
|
||||
# in both the Czech Republic and Slovakia.)
|
||||
# https://www.psp.cz/eknih/1945pns/tisky/t0216_00.htm
|
||||
# (This is a link to the original legislative proposal dating back to
|
||||
# February 22, 1946. The accompanying memorandum to the proposal says
|
||||
# that an advisory committee on European railroad transportation that
|
||||
# met in Brussels in October 1945 decided that the change of time
|
||||
# should be carried out in all participating countries in a strictly
|
||||
# coordinated manner....)
|
||||
#
|
||||
# From Paul Eggert (2024-01-30):
|
||||
# The source for Czech data is: Kdy začíná a končí letní čas.
|
||||
# https://kalendar.beda.cz/kdy-zacina-a-konci-letni-cas
|
||||
# Its main text disagrees with its quoted sources only in 1918,
|
||||
# where the main text says spring and autumn transitions
|
||||
# occurred at 02:00 and 03:00 respectively (as usual),
|
||||
# whereas the 1918 source "Oznámení o zavedení letního času v roce 1918"
|
||||
# says transitions were at 01:00 and 02:00 respectively.
|
||||
# As the 1918 source appears to be a humorous piece, and it is
|
||||
# unlikely that Prague would have disagreed with its neighbors by an hour,
|
||||
# go with the main text for now.
|
||||
#
|
||||
# We know of no English-language name for historical Czech winter time;
|
||||
# abbreviate it as "GMT", as it happened to be GMT.
|
||||
#
|
||||
|
|
|
@ -1,255 +1,120 @@
|
|||
# ATOMIC TIME.
|
||||
# The Coordinated Universal Time (UTC) is the reference time scale derived
|
||||
# from The "Temps Atomique International" (TAI) calculated by the Bureau
|
||||
# International des Poids et Mesures (BIPM) using a worldwide network of atomic
|
||||
# clocks. UTC differs from TAI by an integer number of seconds; it is the basis
|
||||
# of all activities in the world.
|
||||
#
|
||||
# In the following text, the symbol '#' introduces
|
||||
# a comment, which continues from that symbol until
|
||||
# the end of the line. A plain comment line has a
|
||||
# whitespace character following the comment indicator.
|
||||
# There are also special comment lines defined below.
|
||||
# A special comment will always have a non-whitespace
|
||||
# character in column 2.
|
||||
#
|
||||
# A blank line should be ignored.
|
||||
# ASTRONOMICAL TIME (UT1) is the time scale based on the rate of rotation of the earth.
|
||||
# It is now mainly derived from Very Long Baseline Interferometry (VLBI). The various
|
||||
# irregular fluctuations progressively detected in the rotation rate of the Earth lead
|
||||
# in 1972 to the replacement of UT1 by UTC as the reference time scale.
|
||||
#
|
||||
# The following table shows the corrections that must
|
||||
# be applied to compute International Atomic Time (TAI)
|
||||
# from the Coordinated Universal Time (UTC) values that
|
||||
# are transmitted by almost all time services.
|
||||
#
|
||||
# The first column shows an epoch as a number of seconds
|
||||
# since 1 January 1900, 00:00:00 (1900.0 is also used to
|
||||
# indicate the same epoch.) Both of these time stamp formats
|
||||
# ignore the complexities of the time scales that were
|
||||
# used before the current definition of UTC at the start
|
||||
# of 1972. (See note 3 below.)
|
||||
# The second column shows the number of seconds that
|
||||
# must be added to UTC to compute TAI for any timestamp
|
||||
# at or after that epoch. The value on each line is
|
||||
# valid from the indicated initial instant until the
|
||||
# epoch given on the next one or indefinitely into the
|
||||
# future if there is no next line.
|
||||
# (The comment on each line shows the representation of
|
||||
# the corresponding initial epoch in the usual
|
||||
# day-month-year format. The epoch always begins at
|
||||
# 00:00:00 UTC on the indicated day. See Note 5 below.)
|
||||
# LEAP SECOND
|
||||
# Atomic clocks are more stable than the rate of the earth rotation since the latter
|
||||
# undergoes a full range of geophysical perturbations at various time scales: lunisolar
|
||||
# and core-mantle torques, atmospheric and oceanic effetcs, etc.
|
||||
# Leap seconds are needed to keep the two time scales in agreement, i.e. UT1-UTC smaller
|
||||
# than 0.9 second. Therefore, when necessary a "leap second" is applied to UTC.
|
||||
# Since the adoption of this system in 1972 it has been necessary to add a number of seconds to UTC,
|
||||
# firstly due to the initial choice of the value of the second (1/86400 mean solar day of
|
||||
# the year 1820) and secondly to the general slowing down of the Earth's rotation. It is
|
||||
# theorically possible to have a negative leap second (a second removed from UTC), but so far,
|
||||
# all leap seconds have been positive (a second has been added to UTC). Based on what we know about
|
||||
# the earth's rotation, it is unlikely that we will ever have a negative leap second.
|
||||
#
|
||||
# Important notes:
|
||||
#
|
||||
# 1. Coordinated Universal Time (UTC) is often referred to
|
||||
# as Greenwich Mean Time (GMT). The GMT time scale is no
|
||||
# longer used, and the use of GMT to designate UTC is
|
||||
# discouraged.
|
||||
# HISTORY
|
||||
# The first leap second was added on June 30, 1972. Until yhe year 2000, it was necessary in average to add a
|
||||
# leap second at a rate of 1 to 2 years. Since the year 2000 leap seconds are introduced with an
|
||||
# average interval of 3 to 4 years due to the acceleration of the Earth rotation speed.
|
||||
#
|
||||
# 2. The UTC time scale is realized by many national
|
||||
# laboratories and timing centers. Each laboratory
|
||||
# identifies its realization with its name: Thus
|
||||
# UTC(NIST), UTC(USNO), etc. The differences among
|
||||
# these different realizations are typically on the
|
||||
# order of a few nanoseconds (i.e., 0.000 000 00x s)
|
||||
# and can be ignored for many purposes. These differences
|
||||
# are tabulated in Circular T, which is published monthly
|
||||
# by the International Bureau of Weights and Measures
|
||||
# (BIPM). See www.bipm.org for more information.
|
||||
#
|
||||
# 3. The current definition of the relationship between UTC
|
||||
# and TAI dates from 1 January 1972. A number of different
|
||||
# time scales were in use before that epoch, and it can be
|
||||
# quite difficult to compute precise timestamps and time
|
||||
# intervals in those "prehistoric" days. For more information,
|
||||
# consult:
|
||||
# RESPONSABILITY OF THE DECISION TO INTRODUCE A LEAP SECOND IN UTC
|
||||
# The decision to introduce a leap second in UTC is the responsibility of the Earth Orientation Center of
|
||||
# the International Earth Rotation and reference System Service (IERS). This center is located at Paris
|
||||
# Observatory. According to international agreements, leap seconds should only be scheduled for certain dates:
|
||||
# first preference is given to the end of December and June, and second preference at the end of March
|
||||
# and September. Since the introduction of leap seconds in 1972, only dates in June and December were used.
|
||||
#
|
||||
# The Explanatory Supplement to the Astronomical
|
||||
# Ephemeris.
|
||||
# or
|
||||
# Terry Quinn, "The BIPM and the Accurate Measurement
|
||||
# of Time," Proc. of the IEEE, Vol. 79, pp. 894-905,
|
||||
# July, 1991. <http://dx.doi.org/10.1109/5.84965>
|
||||
# reprinted in:
|
||||
# Christine Hackman and Donald B Sullivan (eds.)
|
||||
# Time and Frequency Measurement
|
||||
# American Association of Physics Teachers (1996)
|
||||
# <http://tf.nist.gov/general/pdf/1168.pdf>, pp. 75-86
|
||||
# Questions or comments to:
|
||||
# Christian Bizouard: christian.bizouard@obspm.fr
|
||||
# Earth orientation Center of the IERS
|
||||
# Paris Observatory, France
|
||||
#
|
||||
# 4. The decision to insert a leap second into UTC is currently
|
||||
# the responsibility of the International Earth Rotation and
|
||||
# Reference Systems Service. (The name was changed from the
|
||||
# International Earth Rotation Service, but the acronym IERS
|
||||
# is still used.)
|
||||
#
|
||||
# Leap seconds are announced by the IERS in its Bulletin C.
|
||||
#
|
||||
# See www.iers.org for more details.
|
||||
# COPYRIGHT STATUS OF THIS FILE
|
||||
# This file is in the public domain.
|
||||
#
|
||||
# Every national laboratory and timing center uses the
|
||||
# data from the BIPM and the IERS to construct UTC(lab),
|
||||
# their local realization of UTC.
|
||||
#
|
||||
# Although the definition also includes the possibility
|
||||
# of dropping seconds ("negative" leap seconds), this has
|
||||
# never been done and is unlikely to be necessary in the
|
||||
# foreseeable future.
|
||||
# VALIDITY OF THE FILE
|
||||
# It is important to express the validity of the file. These next two dates are
|
||||
# given in units of seconds since 1900.0.
|
||||
#
|
||||
# 5. If your system keeps time as the number of seconds since
|
||||
# some epoch (e.g., NTP timestamps), then the algorithm for
|
||||
# assigning a UTC time stamp to an event that happens during a positive
|
||||
# leap second is not well defined. The official name of that leap
|
||||
# second is 23:59:60, but there is no way of representing that time
|
||||
# in these systems.
|
||||
# Many systems of this type effectively stop the system clock for
|
||||
# one second during the leap second and use a time that is equivalent
|
||||
# to 23:59:59 UTC twice. For these systems, the corresponding TAI
|
||||
# timestamp would be obtained by advancing to the next entry in the
|
||||
# following table when the time equivalent to 23:59:59 UTC
|
||||
# is used for the second time. Thus the leap second which
|
||||
# occurred on 30 June 1972 at 23:59:59 UTC would have TAI
|
||||
# timestamps computed as follows:
|
||||
# 1) Last update of the file.
|
||||
#
|
||||
# ...
|
||||
# 30 June 1972 23:59:59 (2287785599, first time): TAI= UTC + 10 seconds
|
||||
# 30 June 1972 23:59:60 (2287785599,second time): TAI= UTC + 11 seconds
|
||||
# 1 July 1972 00:00:00 (2287785600) TAI= UTC + 11 seconds
|
||||
# ...
|
||||
# Updated through IERS Bulletin C (https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat)
|
||||
#
|
||||
# If your system realizes the leap second by repeating 00:00:00 UTC twice
|
||||
# (this is possible but not usual), then the advance to the next entry
|
||||
# in the table must occur the second time that a time equivalent to
|
||||
# 00:00:00 UTC is used. Thus, using the same example as above:
|
||||
# The following line shows the last update of this file in NTP timestamp:
|
||||
#
|
||||
# ...
|
||||
# 30 June 1972 23:59:59 (2287785599): TAI= UTC + 10 seconds
|
||||
# 30 June 1972 23:59:60 (2287785600, first time): TAI= UTC + 10 seconds
|
||||
# 1 July 1972 00:00:00 (2287785600,second time): TAI= UTC + 11 seconds
|
||||
# ...
|
||||
#$ 3913697179
|
||||
#
|
||||
# in both cases the use of timestamps based on TAI produces a smooth
|
||||
# time scale with no discontinuity in the time interval. However,
|
||||
# although the long-term behavior of the time scale is correct in both
|
||||
# methods, the second method is technically not correct because it adds
|
||||
# the extra second to the wrong day.
|
||||
# 2) Expiration date of the file given on a semi-annual basis: last June or last December
|
||||
#
|
||||
# This complexity would not be needed for negative leap seconds (if they
|
||||
# are ever used). The UTC time would skip 23:59:59 and advance from
|
||||
# 23:59:58 to 00:00:00 in that case. The TAI offset would decrease by
|
||||
# 1 second at the same instant. This is a much easier situation to deal
|
||||
# with, since the difficulty of unambiguously representing the epoch
|
||||
# during the leap second does not arise.
|
||||
# File expires on 28 December 2024
|
||||
#
|
||||
# Some systems implement leap seconds by amortizing the leap second
|
||||
# over the last few minutes of the day. The frequency of the local
|
||||
# clock is decreased (or increased) to realize the positive (or
|
||||
# negative) leap second. This method removes the time step described
|
||||
# above. Although the long-term behavior of the time scale is correct
|
||||
# in this case, this method introduces an error during the adjustment
|
||||
# period both in time and in frequency with respect to the official
|
||||
# definition of UTC.
|
||||
# Expire date in NTP timestamp:
|
||||
#
|
||||
# Questions or comments to:
|
||||
# Judah Levine
|
||||
# Time and Frequency Division
|
||||
# NIST
|
||||
# Boulder, Colorado
|
||||
# Judah.Levine@nist.gov
|
||||
#@ 3944332800
|
||||
#
|
||||
# Last Update of leap second values: 8 July 2016
|
||||
#
|
||||
# The following line shows this last update date in NTP timestamp
|
||||
# format. This is the date on which the most recent change to
|
||||
# the leap second data was added to the file. This line can
|
||||
# be identified by the unique pair of characters in the first two
|
||||
# columns as shown below.
|
||||
# LIST OF LEAP SECONDS
|
||||
# NTP timestamp (X parameter) is the number of seconds since 1900.0
|
||||
#
|
||||
#$ 3676924800
|
||||
# MJD: The Modified Julian Day number. MJD = X/86400 + 15020
|
||||
#
|
||||
# The NTP timestamps are in units of seconds since the NTP epoch,
|
||||
# which is 1 January 1900, 00:00:00. The Modified Julian Day number
|
||||
# corresponding to the NTP time stamp, X, can be computed as
|
||||
# DTAI: The difference DTAI= TAI-UTC in units of seconds
|
||||
# It is the quantity to add to UTC to get the time in TAI
|
||||
#
|
||||
# X/86400 + 15020
|
||||
# Day Month Year : epoch in clear
|
||||
#
|
||||
# where the first term converts seconds to days and the second
|
||||
# term adds the MJD corresponding to the time origin defined above.
|
||||
# The integer portion of the result is the integer MJD for that
|
||||
# day, and any remainder is the time of day, expressed as the
|
||||
# fraction of the day since 0 hours UTC. The conversion from day
|
||||
# fraction to seconds or to hours, minutes, and seconds may involve
|
||||
# rounding or truncation, depending on the method used in the
|
||||
# computation.
|
||||
#NTP Time DTAI Day Month Year
|
||||
#
|
||||
# The data in this file will be updated periodically as new leap
|
||||
# seconds are announced. In addition to being entered on the line
|
||||
# above, the update time (in NTP format) will be added to the basic
|
||||
# file name leap-seconds to form the name leap-seconds.<NTP TIME>.
|
||||
# In addition, the generic name leap-seconds.list will always point to
|
||||
# the most recent version of the file.
|
||||
2272060800 10 # 1 Jan 1972
|
||||
2287785600 11 # 1 Jul 1972
|
||||
2303683200 12 # 1 Jan 1973
|
||||
2335219200 13 # 1 Jan 1974
|
||||
2366755200 14 # 1 Jan 1975
|
||||
2398291200 15 # 1 Jan 1976
|
||||
2429913600 16 # 1 Jan 1977
|
||||
2461449600 17 # 1 Jan 1978
|
||||
2492985600 18 # 1 Jan 1979
|
||||
2524521600 19 # 1 Jan 1980
|
||||
2571782400 20 # 1 Jul 1981
|
||||
2603318400 21 # 1 Jul 1982
|
||||
2634854400 22 # 1 Jul 1983
|
||||
2698012800 23 # 1 Jul 1985
|
||||
2776982400 24 # 1 Jan 1988
|
||||
2840140800 25 # 1 Jan 1990
|
||||
2871676800 26 # 1 Jan 1991
|
||||
2918937600 27 # 1 Jul 1992
|
||||
2950473600 28 # 1 Jul 1993
|
||||
2982009600 29 # 1 Jul 1994
|
||||
3029443200 30 # 1 Jan 1996
|
||||
3076704000 31 # 1 Jul 1997
|
||||
3124137600 32 # 1 Jan 1999
|
||||
3345062400 33 # 1 Jan 2006
|
||||
3439756800 34 # 1 Jan 2009
|
||||
3550089600 35 # 1 Jul 2012
|
||||
3644697600 36 # 1 Jul 2015
|
||||
3692217600 37 # 1 Jan 2017
|
||||
#
|
||||
# This update procedure will be performed only when a new leap second
|
||||
# is announced.
|
||||
# A hash code has been generated to be able to verify the integrity
|
||||
# of this file. For more information about using this hash code,
|
||||
# please see the readme file in the 'source' directory :
|
||||
# https://hpiers.obspm.fr/iers/bul/bulc/ntp/sources/README
|
||||
#
|
||||
# The following entry specifies the expiration date of the data
|
||||
# in this file in units of seconds since the origin at the instant
|
||||
# 1 January 1900, 00:00:00. This expiration date will be changed
|
||||
# at least twice per year whether or not a new leap second is
|
||||
# announced. These semi-annual changes will be made no later
|
||||
# than 1 June and 1 December of each year to indicate what
|
||||
# action (if any) is to be taken on 30 June and 31 December,
|
||||
# respectively. (These are the customary effective dates for new
|
||||
# leap seconds.) This expiration date will be identified by a
|
||||
# unique pair of characters in columns 1 and 2 as shown below.
|
||||
# In the unlikely event that a leap second is announced with an
|
||||
# effective date other than 30 June or 31 December, then this
|
||||
# file will be edited to include that leap second as soon as it is
|
||||
# announced or at least one month before the effective date
|
||||
# (whichever is later).
|
||||
# If an announcement by the IERS specifies that no leap second is
|
||||
# scheduled, then only the expiration date of the file will
|
||||
# be advanced to show that the information in the file is still
|
||||
# current -- the update time stamp, the data and the name of the file
|
||||
# will not change.
|
||||
#
|
||||
# Updated through IERS Bulletin C66
|
||||
# File expires on: 28 June 2024
|
||||
#
|
||||
#@ 3928521600
|
||||
#
|
||||
2272060800 10 # 1 Jan 1972
|
||||
2287785600 11 # 1 Jul 1972
|
||||
2303683200 12 # 1 Jan 1973
|
||||
2335219200 13 # 1 Jan 1974
|
||||
2366755200 14 # 1 Jan 1975
|
||||
2398291200 15 # 1 Jan 1976
|
||||
2429913600 16 # 1 Jan 1977
|
||||
2461449600 17 # 1 Jan 1978
|
||||
2492985600 18 # 1 Jan 1979
|
||||
2524521600 19 # 1 Jan 1980
|
||||
2571782400 20 # 1 Jul 1981
|
||||
2603318400 21 # 1 Jul 1982
|
||||
2634854400 22 # 1 Jul 1983
|
||||
2698012800 23 # 1 Jul 1985
|
||||
2776982400 24 # 1 Jan 1988
|
||||
2840140800 25 # 1 Jan 1990
|
||||
2871676800 26 # 1 Jan 1991
|
||||
2918937600 27 # 1 Jul 1992
|
||||
2950473600 28 # 1 Jul 1993
|
||||
2982009600 29 # 1 Jul 1994
|
||||
3029443200 30 # 1 Jan 1996
|
||||
3076704000 31 # 1 Jul 1997
|
||||
3124137600 32 # 1 Jan 1999
|
||||
3345062400 33 # 1 Jan 2006
|
||||
3439756800 34 # 1 Jan 2009
|
||||
3550089600 35 # 1 Jul 2012
|
||||
3644697600 36 # 1 Jul 2015
|
||||
3692217600 37 # 1 Jan 2017
|
||||
#
|
||||
# the following special comment contains the
|
||||
# hash value of the data in this file computed
|
||||
# use the secure hash algorithm as specified
|
||||
# by FIPS 180-1. See the files in ~/pub/sha for
|
||||
# the details of how this hash value is
|
||||
# computed. Note that the hash computation
|
||||
# ignores comments and whitespace characters
|
||||
# in data lines. It includes the NTP values
|
||||
# of both the last modification time and the
|
||||
# expiration time of the file, but not the
|
||||
# white space on those lines.
|
||||
# the hash line is also ignored in the
|
||||
# computation.
|
||||
#
|
||||
#h 16edd0f0 3666784f 37db6bdd e74ced87 59af48f1
|
||||
#h 9dac5845 8acd32c0 2947d462 daf4a943 f58d9391
|
||||
|
|
|
@ -3,13 +3,10 @@
|
|||
# This file is in the public domain.
|
||||
|
||||
# This file is generated automatically from the data in the public-domain
|
||||
# NIST format leap-seconds.list file, which can be copied from
|
||||
# <ftp://ftp.nist.gov/pub/time/leap-seconds.list>
|
||||
# or <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>.
|
||||
# The NIST file is used instead of its IERS upstream counterpart
|
||||
# NIST/IERS format leap-seconds.list file, which can be copied from
|
||||
# <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>
|
||||
# because under US law the NIST file is public domain
|
||||
# whereas the IERS file's copyright and license status is unclear.
|
||||
# or, in a variant with different comments, from
|
||||
# <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>.
|
||||
# For more about leap-seconds.list, please see
|
||||
# The NTP Timescale and Leap Seconds
|
||||
# <https://www.eecis.udel.edu/~mills/leap.html>.
|
||||
|
@ -72,11 +69,11 @@ Leap 2016 Dec 31 23:59:60 + S
|
|||
# Any additional leap seconds will come after this.
|
||||
# This Expires line is commented out for now,
|
||||
# so that pre-2020a zic implementations do not reject this file.
|
||||
#Expires 2024 Jun 28 00:00:00
|
||||
#Expires 2024 Dec 28 00:00:00
|
||||
|
||||
# POSIX timestamps for the data in this file:
|
||||
#updated 1467936000 (2016-07-08 00:00:00 UTC)
|
||||
#expires 1719532800 (2024-06-28 00:00:00 UTC)
|
||||
#updated 1704708379 (2024-01-08 10:06:19 UTC)
|
||||
#expires 1735344000 (2024-12-28 00:00:00 UTC)
|
||||
|
||||
# Updated through IERS Bulletin C66
|
||||
# File expires on: 28 June 2024
|
||||
# Updated through IERS Bulletin C (https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat)
|
||||
# File expires on 28 December 2024
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
# Generate zic format 'leapseconds' from NIST format 'leap-seconds.list'.
|
||||
# Generate zic format 'leapseconds' from NIST/IERS format 'leap-seconds.list'.
|
||||
|
||||
# This file is in the public domain.
|
||||
|
||||
|
@ -21,13 +21,10 @@ BEGIN {
|
|||
print "# This file is in the public domain."
|
||||
print ""
|
||||
print "# This file is generated automatically from the data in the public-domain"
|
||||
print "# NIST format leap-seconds.list file, which can be copied from"
|
||||
print "# <ftp://ftp.nist.gov/pub/time/leap-seconds.list>"
|
||||
print "# or <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>."
|
||||
print "# The NIST file is used instead of its IERS upstream counterpart"
|
||||
print "# NIST/IERS format leap-seconds.list file, which can be copied from"
|
||||
print "# <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>"
|
||||
print "# because under US law the NIST file is public domain"
|
||||
print "# whereas the IERS file's copyright and license status is unclear."
|
||||
print "# or, in a variant with different comments, from"
|
||||
print "# <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>."
|
||||
print "# For more about leap-seconds.list, please see"
|
||||
print "# The NTP Timescale and Leap Seconds"
|
||||
print "# <https://www.eecis.udel.edu/~mills/leap.html>."
|
||||
|
|
|
@ -1268,6 +1268,10 @@ Zone America/Menominee -5:50:27 - LMT 1885 Sep 18 12:00
|
|||
# <http://cs.ucla.edu/~eggert/The-Waste-of-Daylight-19th.pdf>
|
||||
# [PDF] (1914-03)
|
||||
#
|
||||
# For the 1911/1912 establishment of standard time in French possessions, see:
|
||||
# Société Française de Physique, Recueil de constantes physiques (1913),
|
||||
# page 752, 18b.
|
||||
#
|
||||
# See the 'europe' file for Greenland.
|
||||
|
||||
# Canada
|
||||
|
@ -1354,7 +1358,7 @@ Zone America/Menominee -5:50:27 - LMT 1885 Sep 18 12:00
|
|||
# From Paul Eggert (2014-10-18):
|
||||
# H. David Matthews and Mary Vincent's map
|
||||
# "It's about TIME", _Canadian Geographic_ (September-October 1998)
|
||||
# http://www.canadiangeographic.ca/Magazine/SO98/alacarte.asp
|
||||
# https://web.archive.org/web/19990827055050/https://canadiangeographic.ca/SO98/geomap.htm
|
||||
# contains detailed boundaries for regions observing nonstandard
|
||||
# time and daylight saving time arrangements in Canada circa 1998.
|
||||
#
|
||||
|
@ -1646,6 +1650,15 @@ Zone America/Blanc-Sablon -3:48:28 - LMT 1884
|
|||
# Some cities in the United States have pushed the deadline back
|
||||
# three weeks and will change over from daylight saving in October.
|
||||
|
||||
# From Chris Walton (2024-01-09):
|
||||
# The [Toronto] changes in 1947, 1948, and 1949 took place at 2:00 a.m. local
|
||||
# time instead of midnight.... Toronto Daily Star - ...
|
||||
# April 2, 1947 - Page 39 ... April 7, 1948 - Page 13 ...
|
||||
# April 2, 1949 - Page 1 ... April 7, 1949 - Page 24 ...
|
||||
# November 25, 1949 - Page 52 ... April 21, 1950 - Page 14 ...
|
||||
# September 19, 1950 - Page 46 ... September 20, 1950 - Page 3 ...
|
||||
# November 24, 1950 - Page 21
|
||||
|
||||
# From Arthur David Olson (2010-07-17):
|
||||
#
|
||||
# "Standard Time and Time Zones in Canada" appeared in
|
||||
|
@ -1707,13 +1720,9 @@ Rule Toronto 1927 1937 - Sep Sun>=25 2:00 0 S
|
|||
Rule Toronto 1928 1937 - Apr Sun>=25 2:00 1:00 D
|
||||
Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D
|
||||
Rule Toronto 1938 1939 - Sep lastSun 2:00 0 S
|
||||
Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S
|
||||
Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D
|
||||
Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D
|
||||
Rule Toronto 1947 1948 - Sep lastSun 0:00 0 S
|
||||
Rule Toronto 1949 only - Nov lastSun 0:00 0 S
|
||||
Rule Toronto 1950 1973 - Apr lastSun 2:00 1:00 D
|
||||
Rule Toronto 1950 only - Nov lastSun 2:00 0 S
|
||||
Rule Toronto 1945 1948 - Sep lastSun 2:00 0 S
|
||||
Rule Toronto 1946 1973 - Apr lastSun 2:00 1:00 D
|
||||
Rule Toronto 1949 1950 - Nov lastSun 2:00 0 S
|
||||
Rule Toronto 1951 1956 - Sep lastSun 2:00 0 S
|
||||
# Shanks & Pottenger say Toronto ended DST a week early in 1971,
|
||||
# namely on 1971-10-24, but Mark Brader wrote (2003-05-31) that this
|
||||
|
@ -3501,7 +3510,7 @@ Zone America/Jamaica -5:07:10 - LMT 1890 # Kingston
|
|||
# Martinique
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
Zone America/Martinique -4:04:20 - LMT 1890 # Fort-de-France
|
||||
-4:04:20 - FFMT 1911 May # Fort-de-France MT
|
||||
-4:04:20 - FFMT 1911 May 1 # Fort-de-France MT
|
||||
-4:00 - AST 1980 Apr 6
|
||||
-4:00 1:00 ADT 1980 Sep 28
|
||||
-4:00 - AST
|
||||
|
@ -3604,7 +3613,7 @@ Zone America/St_Lucia -4:04:00 - LMT 1890 # Castries
|
|||
# St Pierre and Miquelon
|
||||
# There are too many St Pierres elsewhere, so we'll use 'Miquelon'.
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre
|
||||
Zone America/Miquelon -3:44:40 - LMT 1911 Jun 15 # St Pierre
|
||||
-4:00 - AST 1980 May
|
||||
-3:00 - -03 1987
|
||||
-3:00 Canada -03/-02
|
||||
|
|
|
@ -1583,8 +1583,11 @@ Zone Atlantic/Stanley -3:51:24 - LMT 1890
|
|||
-3:00 - -03
|
||||
|
||||
# French Guiana
|
||||
# For the 1911/1912 establishment of standard time in French possessions, see:
|
||||
# Société Française de Physique, Recueil de constantes physiques (1913),
|
||||
# page 752, 18b.
|
||||
# Zone NAME STDOFF RULES FORMAT [UNTIL]
|
||||
Zone America/Cayenne -3:29:20 - LMT 1911 Jul
|
||||
Zone America/Cayenne -3:29:20 - LMT 1911 Jul 1
|
||||
-4:00 - -04 1967 Oct
|
||||
-3:00 - -03
|
||||
|
||||
|
|
|
@ -95,7 +95,7 @@ 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.
|
||||
standard and daylight saving times supported by POSIX.1-2017.
|
||||
A <code><abbr>tz</abbr></code> timezone 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
|
||||
|
@ -187,7 +187,7 @@ in decreasing order of importance:
|
|||
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="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">POSIX
|
||||
href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">POSIX.1-2017
|
||||
<code>TZ</code> strings</a>.
|
||||
A file name component must not exceed 14 characters or start with
|
||||
'<code>-</code>'.
|
||||
|
@ -362,6 +362,11 @@ The backward-compatibility file <code>zone.tab</code> is similar
|
|||
but conforms to the older-version guidelines related to <abbr>ISO</abbr> 3166-1;
|
||||
it lists only one country code per entry and unlike <code>zone1970.tab</code>
|
||||
it can list names defined in <code>backward</code>.
|
||||
Applications that process only timestamps from now on can instead use the file
|
||||
<code>zonenow.tab</code>, which partitions the world more coarsely,
|
||||
into regions where clocks agree now and in the predicted future;
|
||||
this file is smaller and simpler than <code>zone1970.tab</code>
|
||||
and <code>zone.tab</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
@ -373,7 +378,7 @@ nowadays distributions typically use it
|
|||
and no great weight should be attached to whether a link
|
||||
is defined in <code>backward</code> or in some other file.
|
||||
The source file <code>etcetera</code> defines names that may be useful
|
||||
on platforms that do not support POSIX-style <code>TZ</code> strings;
|
||||
on platforms that do not support POSIX.1-2017-style <code>TZ</code> strings;
|
||||
no other source file other than <code>backward</code>
|
||||
contains links to its zones.
|
||||
One of <code>etcetera</code>'s names is <code>Etc/UTC</code>,
|
||||
|
@ -421,7 +426,7 @@ in decreasing order of importance:
|
|||
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.
|
||||
POSIX.1-2017 <code>TZ</code> string.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
|
@ -765,12 +770,12 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes
|
|||
calendar with 24-hour days. These divergences range from
|
||||
relatively minor, such as Japanese bars giving times like "24:30" for the
|
||||
wee hours of the morning, to more-significant differences such as <a
|
||||
href="https://www.pri.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-better-double-check-time">the
|
||||
href="https://theworld.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-better-double-check-time">the
|
||||
east African practice of starting the day at dawn</a>, renumbering
|
||||
the Western 06:00 to be 12:00. These practices are largely outside
|
||||
the scope of the <code><abbr>tz</abbr></code> code and data, which
|
||||
provide only limited support for date and time localization
|
||||
such as that required by POSIX.
|
||||
such as that required by POSIX.1-2017.
|
||||
If <abbr>DST</abbr> is not used a different time zone
|
||||
can often do the trick; for example, in Kenya a <code>TZ</code> setting
|
||||
like <code><-03>3</code> or <code>America/Cayenne</code> starts
|
||||
|
@ -867,23 +872,23 @@ 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>
|
||||
<h3 id="POSIX">POSIX.1-2017 properties and limitations</h3>
|
||||
<ul>
|
||||
<li>
|
||||
<p>
|
||||
In POSIX, time display in a process is controlled by the
|
||||
In POSIX.1-2017, time display in a process is controlled by the
|
||||
environment variable <code>TZ</code>.
|
||||
Unfortunately, the POSIX
|
||||
Unfortunately, the POSIX.1-2017
|
||||
<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
|
||||
Also, POSIX.1-2017 <code>TZ</code> strings cannot deal with daylight
|
||||
saving time rules not based on the Gregorian calendar (as in
|
||||
Morocco), or with situations where more than two time zone
|
||||
abbreviations or <abbr>UT</abbr> offsets are used in an area.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The POSIX <code>TZ</code> string takes the following form:
|
||||
The POSIX.1-2017 <code>TZ</code> string takes the following form:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
@ -950,7 +955,7 @@ an older <code>zic</code>.
|
|||
</dl>
|
||||
|
||||
<p>
|
||||
Here is an example POSIX <code>TZ</code> string for New
|
||||
Here is an example POSIX.1-2017 <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
|
||||
|
@ -961,7 +966,7 @@ an older <code>zic</code>.
|
|||
<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
|
||||
This POSIX.1-2017 <code>TZ</code> string is hard to remember, and
|
||||
mishandles some timestamps before 2008.
|
||||
With this package you can use this instead:
|
||||
</p>
|
||||
|
@ -999,7 +1004,7 @@ an older <code>zic</code>.
|
|||
limit phone calls to off-peak hours.
|
||||
</li>
|
||||
<li>
|
||||
POSIX provides no convenient and efficient way to determine
|
||||
POSIX.1-2017 provides no convenient and efficient way to determine
|
||||
the <abbr>UT</abbr> offset and time zone abbreviation of arbitrary
|
||||
timestamps, particularly for timezones
|
||||
that do not fit into the POSIX model.
|
||||
|
@ -1026,14 +1031,14 @@ an older <code>zic</code>.
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="POSIX-extensions">Extensions to POSIX in the
|
||||
<h3 id="POSIX-extensions">Extensions to POSIX.1-2017 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 file from which time-related information is read
|
||||
(or is interpreted à la POSIX); <code>TZ</code> is no longer
|
||||
(or is interpreted à la POSIX.1-2017); <code>TZ</code> is no longer
|
||||
constrained to be a string containing abbreviations
|
||||
and numeric data as described <a href="#POSIX">above</a>.
|
||||
The file's format is <dfn><abbr>TZif</abbr></dfn>,
|
||||
|
|
|
@ -1 +1 @@
|
|||
2023dgtz
|
||||
2024agtz
|
||||
|
|
|
@ -162,7 +162,7 @@ function make_line(n, field, \
|
|||
# Process the input line LINE and save it for later output.
|
||||
|
||||
function process_input_line(line, \
|
||||
f, field, end, i, n, r, startdef, \
|
||||
f, field, end, n, outline, r, \
|
||||
linkline, ruleline, zoneline)
|
||||
{
|
||||
# Remove comments, normalize spaces, and append a space to each line.
|
||||
|
@ -199,8 +199,10 @@ function process_input_line(line, \
|
|||
}
|
||||
|
||||
# Abbreviate "max", "min", "only" and month names.
|
||||
gsub(/ max /, " ma ", line)
|
||||
gsub(/ min /, " mi ", line)
|
||||
# Although "max" and "min" can both be abbreviated to just "m",
|
||||
# the longer forms "ma" and "mi" are needed with zic 2023d and earlier.
|
||||
gsub(/ max /, dataform == "vanguard" ? " m " : " ma ", line)
|
||||
gsub(/ min /, dataform == "vanguard" ? " m " : " mi ", line)
|
||||
gsub(/ only /, " o ", line)
|
||||
gsub(/ Jan /, " Ja ", line)
|
||||
gsub(/ Feb /, " F ", line)
|
||||
|
@ -234,66 +236,96 @@ function process_input_line(line, \
|
|||
rule_used[r] = 1
|
||||
}
|
||||
|
||||
# If this zone supersedes an earlier one, delete the earlier one
|
||||
# from the saved output lines.
|
||||
startdef = ""
|
||||
if (zoneline)
|
||||
zonename = startdef = field[2]
|
||||
else if (linkline)
|
||||
zonename = startdef = field[3]
|
||||
else if (ruleline)
|
||||
zonename = ""
|
||||
if (startdef) {
|
||||
i = zonedef[startdef]
|
||||
if (i) {
|
||||
do
|
||||
output_line[i - 1] = ""
|
||||
while (output_line[i++] ~ /^[-+0-9]/);
|
||||
}
|
||||
}
|
||||
zonedef[zonename] = nout + 1
|
||||
|
||||
# Save the line for later output.
|
||||
output_line[nout++] = make_line(n, field)
|
||||
# Save the information for later output.
|
||||
outline = make_line(n, field)
|
||||
if (ruleline)
|
||||
rule_output_line[nrule_out++] = outline
|
||||
else if (linkline) {
|
||||
# In vanguard format with Gawk, links are output sorted by destination.
|
||||
if (dataform == "vanguard" && PROCINFO["version"])
|
||||
linkdef[zonename] = field[2]
|
||||
else
|
||||
link_output_line[nlink_out++] = outline
|
||||
}else
|
||||
zonedef[zonename] = (zoneline ? "" : zonedef[zonename] "\n") outline
|
||||
}
|
||||
|
||||
function omit_unused_rules( \
|
||||
i, field)
|
||||
{
|
||||
for (i = 0; i < nout; i++) {
|
||||
split(output_line[i], field)
|
||||
if (field[1] == "R" && !rule_used[field[2]]) {
|
||||
output_line[i] = ""
|
||||
}
|
||||
for (i = 0; i < nrule_out; i++) {
|
||||
split(rule_output_line[i], field)
|
||||
if (!rule_used[field[2]])
|
||||
rule_output_line[i] = ""
|
||||
}
|
||||
}
|
||||
|
||||
function abbreviate_rule_names( \
|
||||
abbr, f, field, i, n, r)
|
||||
abbr, f, field, i, n, newdef, newline, r, \
|
||||
zoneline, zonelines, zonename)
|
||||
{
|
||||
for (i = 0; i < nout; i++) {
|
||||
n = split(output_line[i], field)
|
||||
for (i = 0; i < nrule_out; i++) {
|
||||
n = split(rule_output_line[i], field)
|
||||
if (n) {
|
||||
f = field[1] == "Z" ? 4 : field[1] == "L" ? 0 : 2
|
||||
r = field[f]
|
||||
r = field[2]
|
||||
if (r ~ /^[^-+0-9]/) {
|
||||
abbr = rule[r]
|
||||
if (!abbr) {
|
||||
rule[r] = abbr = gen_rule_name(r)
|
||||
}
|
||||
field[f] = abbr
|
||||
output_line[i] = make_line(n, field)
|
||||
field[2] = abbr
|
||||
rule_output_line[i] = make_line(n, field)
|
||||
}
|
||||
}
|
||||
}
|
||||
for (zonename in zonedef) {
|
||||
zonelines = split(zonedef[zonename], zoneline, /\n/)
|
||||
newdef = ""
|
||||
for (i = 1; i <= zonelines; i++) {
|
||||
newline = zoneline[i]
|
||||
n = split(newline, field)
|
||||
f = i == 1 ? 4 : 2
|
||||
r = rule[field[f]]
|
||||
if (r) {
|
||||
field[f] = r
|
||||
newline = make_line(n, field)
|
||||
}
|
||||
newdef = (newdef ? newdef "\n" : "") newline
|
||||
}
|
||||
zonedef[zonename] = newdef
|
||||
}
|
||||
}
|
||||
|
||||
function output_saved_lines( \
|
||||
i)
|
||||
i, zonename)
|
||||
{
|
||||
for (i = 0; i < nout; i++)
|
||||
if (output_line[i])
|
||||
print output_line[i]
|
||||
for (i = 0; i < nrule_out; i++)
|
||||
if (rule_output_line[i])
|
||||
print rule_output_line[i]
|
||||
|
||||
# When using gawk, output zones sorted by name.
|
||||
# This makes the output a bit more compressible.
|
||||
PROCINFO["sorted_in"] = "@ind_str_asc"
|
||||
for (zonename in zonedef)
|
||||
print zonedef[zonename]
|
||||
|
||||
if (nlink_out)
|
||||
for (i = 0; i < nlink_out; i++)
|
||||
print link_output_line[i]
|
||||
else {
|
||||
# When using gawk, output links sorted by destination.
|
||||
# This also helps compressibility a bit.
|
||||
PROCINFO["sorted_in"] = "@val_type_asc"
|
||||
for (zonename in linkdef)
|
||||
printf "L %s %s\n", linkdef[zonename], zonename
|
||||
}
|
||||
}
|
||||
|
||||
BEGIN {
|
||||
|
|
|
@ -199,7 +199,7 @@ XX +2518+05518 Asia/Dubai Russia; Caucasus; Persian Gulf; Seychelles; Réunion
|
|||
XX +3431+06912 Asia/Kabul Afghanistan
|
||||
#
|
||||
# +05
|
||||
XX +4120+06918 Asia/Tashkent Russia; Tajikistan; Turkmenistan; Uzbekistan; Maldives
|
||||
XX +4120+06918 Asia/Tashkent Russia; west Kazakhstan; Tajikistan; Turkmenistan; Uzbekistan; Maldives
|
||||
#
|
||||
# +05 - PKT
|
||||
XX +2452+06703 Asia/Karachi Pakistan ("PKT")
|
||||
|
@ -215,6 +215,8 @@ XX +2743+08519 Asia/Kathmandu Nepal
|
|||
#
|
||||
# +06
|
||||
XX +2343+09025 Asia/Dhaka Russia; Kyrgyzstan; Bhutan; Bangladesh; Chagos
|
||||
# +06 until 2024-03-01; then +05
|
||||
XX +4315+07657 Asia/Almaty Kazakhstan (except western areas)
|
||||
#
|
||||
# +06:30
|
||||
XX +1647+09610 Asia/Yangon Myanmar; Cocos
|
||||
|
|
Loading…
Reference in New Issue