July 2022 - tz - lists.iana.org

Re: [tz] [PROPOSED 3/3] Vanguard form now uses subsecond precision -Brooks
by Steve Allen July 31, 2022

July 31, 2022

On Sat 2022-07-30T13:24:01-0400 Brooks Harris hath writ: > On 2022-07-30 1:01 PM, Paul Eggert via tz wrote: > > Given the other comments in this thread I'm inclined to revert the > > effect of this change, so that vanguard form continues to use integer > > multiples of a second. So I installed the attached further patches, the > > last of which does the reversion. > I think that's best for civil time. But I had a thought. Steve Allen seemed > to like the idea and I'm sympathetic to his needs as astronomer. Maybe > subsecond precision could be added to "right" instead of vanguard? No, tz does not need subsecond precision, not for anyone, not in any era. The French law of 9m 21s is an example. The legislators should have known about the funds which had been expended as part of the two century effort to establish the offset between Greenwich and Paris, and that the disagreements of many 0.1 s in their own lifetimes were from the techniques employed by the astronomers, not from the telegraphs or radios. The sub-second astronomical offsets all date from before the 1970 cutoff. 1970 was when the CCIR was persuaded to assert that one second is close enough for everyone. Historically the best time comparisons had poor precision. Before the 20th century offsets were many 0.1 s or even > 1 s. In the early 20th century offsets were still many 0.01 s or even > 1 s. Attempts to reach a precision of 0.0001 s were not widespread until the International Geophysical Year of 1957/1958. Offsets of many 0.001 s persisted after the adoption of the cesium-based coordinated time because the Soviets used their own coordination scheme and other countries did not convert from UT2 to coordinated cesium time until the late 1960s. tz has rightfully eschewed the notion of trying to track local offsets recorded in Bulletin Horaire and Circular T. The legal time of the US was offset by 0.035 seconds from the BIH at 1958-01-01. The USNO and US NBS did not attempt to bring their time scales into microsecond agreement until 1968. Over a long interval in this century the legal time of Hungary was 50 microseconds different from UTC in most other places because the time lab there declined to perform a reset of their cesium. Thinking of encoding these things is a world of pain that tz does not need. -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

3 3

[PROPOSED] Check that ziguard substitutions revert
by Paul Eggert July 29, 2022

July 29, 2022

Add a check that substitutions to vanguard or rearguard form can be reverted. This supports possible future uses when continental files are in vanguard form and you want rearguard (or vice versa). * Makefile (check): Depend on ... (check_ziguard): ... this new target. * ziguard.awk: Fix some in_comment typos, as these column numbers do not depend on whether we’re in a comment. Use sub(X,Y) instead of $I = Y to preserve whitespace. Fix Japan and Morocco substitutions so that they are reversible. --- Makefile | 9 ++++++++- ziguard.awk | 58 ++++++++++++++++++++++++++++++++++++----------------- 2 files changed, 48 insertions(+), 19 deletions(-) diff --git a/Makefile b/Makefile index e3e5c0dd..52d7fdbe 100644 --- a/Makefile +++ b/Makefile @@ -754,7 +754,7 @@ tzselect: tzselect.ksh version check: check_character_set check_white_space check_links \ check_name_lengths check_slashed_abbrs check_sorted \ - check_tables check_web check_zishrink check_tzs + check_tables check_web check_ziguard check_zishrink check_tzs check_character_set: $(ENCHILADA) test ! '$(UTF8_LOCALE)' || \ @@ -839,6 +839,13 @@ check_theory.html check_tz-art.html check_tz-how-to.html check_tz-link.html: test ! -s $@.out || { cat $@.out; exit 1; } mv $@.out $@ +check_ziguard: rearguard.zi vanguard.zi ziguard.awk + $(AWK) -v DATAFORM=rearguard -f ziguard.awk vanguard.zi | \ + diff -u rearguard.zi - + $(AWK) -v DATAFORM=vanguard -f ziguard.awk rearguard.zi | \ + diff -u vanguard.zi - + touch $@ + # Check that zishrink.awk does not alter the data, and that ziguard.awk # preserves main-format data. check_zishrink: check_zishrink_posix check_zishrink_right diff --git a/ziguard.awk b/ziguard.awk index 171b952d..c39e0d65 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -134,8 +134,7 @@ DATAFORM != "main" { || 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")) \ + ? ($9 ~ /^-/ || ($9 == 0 && $10 == "CAT")) \ : $(in_comment + 1) == "2:00" && $(in_comment + 2) == "Namibia") \ == (DATAFORM != "rearguard")) { uncomment = in_comment @@ -219,43 +218,66 @@ DATAFORM != "main" { stdoff_column = 2 * /^Zone/ + 1 stdoff_column_val = $stdoff_column if (stdoff_column_val == stdoff_subst[0]) { - $stdoff_column = stdoff_subst[1] + sub(stdoff_subst[0], stdoff_subst[1]) if (until_subst[0] && $NF == until_subst[0]) { - $NF = until_subst[1] + sub(until_subst[0], until_subst[1]) } } else if (stdoff_column_val != stdoff_subst[1]) { stdoff_subst[0] = 0 } } - if (DATAFORM == "rearguard") { - - # In rearguard form, change the Japan rule line with "Sat>=8 25:00" - # to "Sun>=9 1:00", to cater to zic before 2007 and to older Java. - if (/^Rule/ && $2 == "Japan") { + # In rearguard form, change the Japan rule line with "Sat>=8 25:00" + # to "Sun>=9 1:00", to cater to zic before 2007 and to older Java. + if (/^Rule/ && $2 == "Japan") { + if (DATAFORM == "rearguard") { if ($7 == "Sat>=8" && $8 == "25:00") { sub(/Sat>=8/, "Sun>=9") sub(/25:00/, " 1:00") } + } else { + if ($7 == "Sun>=9" && $8 == "1:00") { + sub(/Sun>=9/, "Sat>=8") + sub(/ 1:00/, "25:00") + } } + } - # In rearguard form, change the Morocco lines with negative SAVE values - # to use positive SAVE values. - if ($2 == "Morocco") { - if (/^Rule/) { - if ($4 == 2018 && $6 == "Oct") { + # In rearguard form, change the Morocco lines with negative SAVE values + # to use positive SAVE values. + if ($2 == "Morocco") { + if (/^Rule/) { + if ($4 ~ /^201[78]$/ && $6 == "Oct") { + if (DATAFORM == "rearguard") { sub(/\t2018\t/, "\t2017\t") + } else { + sub(/\t2017\t/, "\t2018\t") } - if (2019 <= $3) { - if ($9 == "0") { + } + + if (2019 <= $3) { + if ($8 == "2:00") { + if (DATAFORM == "rearguard") { sub(/\t0\t/, "\t1:00\t") } else { + sub(/\t1:00\t/, "\t0\t") + } + } else { + if (DATAFORM == "rearguard") { sub(/\t-1:00\t/, "\t0\t") + } else { + sub(/\t0\t/, "\t-1:00\t") } } } - if ($1 == "1:00" && $3 == "+01/+00") { - sub(/1:00\tMorocco\t\+01\/\+00$/, "0:00\tMorocco\t+00/+01") + } + if ($1 ~ /^[+0-9-]/ && NF == 3) { + if (DATAFORM == "rearguard") { + sub(/1:00\tMorocco/, "0:00\tMorocco") + sub(/\t\+01\/\+00$/, "\t+00/+01") + } else { + sub(/0:00\tMorocco/, "1:00\tMorocco") + sub(/\t\+00\/+01$/, "\t+01/+00") } } } -- 2.34.1

1 0

[PROPOSED 1/2] New ‘make’ target tailored_tarballs
by Paul Eggert July 28, 2022

July 28, 2022

* Makefile (tailored_tarballs, tailored_tarballs_version) (tzdata$(VERSION)-tailored.tar.gz): New rules. (CREATE_EMPTY): New macro. (tzdata$(VERSION)-rearguard.tar.gz, tzdata$(VERSION)-vanguard.tar.gz): Use it. --- Makefile | 66 ++++++++++++++++++++++++++++++++++++++++++++------------ NEWS | 6 ++++++ 2 files changed, 58 insertions(+), 14 deletions(-) diff --git a/Makefile b/Makefile index 79910d8..65dc0d8 100644 --- a/Makefile +++ b/Makefile @@ -1039,9 +1039,9 @@ REARGUARD_ASC = \ ALL_ASC = $(TRADITIONAL_ASC) $(REARGUARD_ASC) \ tzdb-$(VERSION).tar.lz.asc -tarballs rearguard_tarballs traditional_tarballs \ +tarballs rearguard_tarballs tailored_tarballs traditional_tarballs \ signatures rearguard_signatures traditional_signatures: \ - version set-timestamps.out rearguard.zi + version set-timestamps.out rearguard.zi vanguard.zi VERSION=`cat version` && \ $(MAKE) AWK='$(AWK)' VERSION="$$VERSION" $@_version @@ -1054,6 +1054,8 @@ rearguard_tarballs_version: \ tzdata$(VERSION)-rearguard.tar.gz traditional_tarballs_version: \ tzcode$(VERSION).tar.gz tzdata$(VERSION).tar.gz +tailored_tarballs_version: \ + tzdata$(VERSION)-tailored.tar.gz signatures_version: $(ALL_ASC) rearguard_signatures_version: $(REARGUARD_ASC) traditional_signatures_version: $(TRADITIONAL_ASC) @@ -1071,30 +1073,65 @@ tzdata$(VERSION).tar.gz: set-timestamps.out gzip $(GZIPFLAGS) >$@.out mv $@.out $@ +# Create empty files with a reproducible timestamp. +CREATE_EMPTY = TZ=UTC0 touch -mt 202010122253.00 + +# The obsolescent *rearguard* targets and related macros are present +# for backwards compatibility with tz releases 2018e through 2022a. +# They should go away eventually. To build rearguard tarballs you +# can instead use 'make DATAFORM=rearguard tailored_tarballs'. 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 + rm -fr $@.dir + mkdir $@.dir + ln $(COMMON) $(DATA) $(MISC) $@.dir + cd $@.dir && rm -f $(TDATA) $(PACKRATDATA) version for f in $(TDATA) $(PACKRATDATA); do \ - rearf=tzdata$(VERSION)-rearguard.dir/$$f; \ + rearf=$@.dir/$$f; \ $(AWK) -v DATAFORM=rearguard -f ziguard.awk $$f >$$rearf && \ $(SET_TIMESTAMP_DEP) $$rearf ziguard.awk $$f || exit; \ done - sed '1s/$$/-rearguard/' \ - <version >tzdata$(VERSION)-rearguard.dir/version + sed '1s/$$/-rearguard/' <version >$@.dir/version : The dummy pacificnew pacifies TZUpdater 2.3.1 and earlier. - TZ=UTC0 touch -mt 202010122253.00 \ - tzdata$(VERSION)-rearguard.dir/pacificnew - touch -cmr version tzdata$(VERSION)-rearguard.dir/version + $(CREATE_EMPTY) $@.dir/pacificnew + touch -cmr version $@.dir/version LC_ALL=C && export LC_ALL && \ - (cd tzdata$(VERSION)-rearguard.dir && \ + (cd $@.dir && \ tar $(TARFLAGS) -cf - \ $(COMMON) $(DATA) $(MISC) pacificnew | \ gzip $(GZIPFLAGS)) >$@.out mv $@.out $@ +# Create a tailored tarball suitable for TZUpdater and compatible tools. +# For example, 'make DATAFORM=vanguard tailored_tarballs' makes a tarball +# useful for testing whether TZUpdater supports vanguard form. +tzdata$(VERSION)-tailored.tar.gz: set-timestamps.out + rm -fr $@.dir + mkdir $@.dir + : The dummy pacificnew pacifies TZUpdater 2.3.1 and earlier. + cd $@.dir && \ + $(CREATE_EMPTY) $(PRIMARY_YDATA) $(NDATA) backward pacificnew + (grep '^#' tzdata.zi && echo && cat $(DATAFORM).zi) \ + >$@.dir/etcetera + touch -cmr tzdata.zi $@.dir/etcetera + sed -n \ + -e '/^# *version *$.*$/h' \ + -e '/^# *ddeps */H' \ + -e '$$!d' \ + -e 'g' \ + -e 's/^# *version *//' \ + -e 's/\n# *ddeps */-/' \ + -e 's/ /-/g' \ + -e 'p' \ + <tzdata.zi >$@.dir/version + touch -cmr version $@.dir/version + LC_ALL=C && export LC_ALL && \ + (cd $@.dir && \ + tar $(TARFLAGS) -cf - \ + $(TDATA_TO_CHECK) version \ + `test $(DATAFORM) = vanguard || echo pacificnew` | \ + gzip $(GZIPFLAGS)) >$@.out + mv $@.out $@ + tzdb-$(VERSION).tar.lz: set-timestamps.out set-tzs-timestamp.out rm -fr tzdb-$(VERSION) mkdir tzdb-$(VERSION) @@ -1153,6 +1190,7 @@ zic.o: private.h tzfile.h version.h .PHONY: tarballs tarballs_version .PHONY: traditional_signatures traditional_signatures_version .PHONY: traditional_tarballs traditional_tarballs_version +.PHONY: tailored_tarballs tailored_tarballs_version .PHONY: typecheck .PHONY: zonenames zones .PHONY: $(ZDS) diff --git a/NEWS b/NEWS index 33261ee..eac1f0a 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,7 @@ Unreleased, experimental changes Rename Europe/Kiev to Europe/Kyiv. New zic -R option Vanguard form now uses %z. + New tailored_tarballs target, replacing rearguard_tarballs Changes to future timestamps @@ -70,6 +71,11 @@ Unreleased, experimental changes to use %z eventually; in the meantime maintainers of zi parsers are encouraged to test the parsers on vanguard.zi. + The Makefile has a new tailored_tarballs target for generating + special-purpose tarballs. It generalizes and replaces the + rearguard_tarballs target and related targets and macros, which + are now obsolescent. + 'make install' now defaults LOCALTIME to Factory not GMT, which means the default abbreviation is now "-00" not "GMT". -- 2.37.1

2 2

Re: [tz] IANA timezone database - request to add Omaha, Nebraska
by Paul Eggert July 26, 2022

July 26, 2022

On 7/26/22 13:15, John Hawkinson wrote: >> If it means to enumerate only Zones and omit Links, which is what I think >> you mean, then readlink will work only if Links are implemented via symbolic >> links. Although Debian and Red Hat based systems do that, the default TZDB >> installation does not (it uses hard links), and Alpine, macOS, NetBSD, >> OpenBSD, OpenSUSE etc. use the default either because it is the default or >> because it is a bit more efficient. > You sure? > > My MacOS 12.5 laptop uses a symlink for /etc/localtime Oh, I was referring to links like these on Ubuntu 22.04: $ ls -l /usr/share/zoneinfo/Europe/Belfast lrwxrwxrwx 1 root root 6 Mar 21 11:29 /usr/share/zoneinfo/Europe/Belfast -> London I was not talking about /etc/localtime, which is a different kettle of fish. PS. Based on my misreading of a quick Google search I said in that quote above that macOS uses hard links for aliases like Europe/Belfast. However, Guy just reported[1] that current Ventura beta uses copies, just like FreeBSD does. Apologies for the error. [1] https://mm.icann.org/pipermail/tz/2022-July/031706.html

3 3

Meta engineers oppose leap seconds
by Paul Eggert July 26, 2022

July 26, 2022

Monty Solomon writes that Meta engineers Oleg Obleukhov and Ahmad Byagowi have come out against leap seconds in “It’s time to leave the leap second in the past”[1], which gives a shoutout to the leap-seconds.list file that Tim just updated in TZDB’s development version. Meta uses a 17-hour quadratic smear starting at midnight UTC, whereas Google and Amazon use a 24-hour linear smear from noon to noon UTC.[2] Obleukhov and Byagowi list several reasons leap seconds are a pain, say that the leap second is doing more harm than good (take that, scientists and astronomers!) and conclude that they “are supporting a larger community push to stop the future introduction of leap seconds”. Although I don’t see any new technical material there, their note prompted me to reread [2] and notice that Google provides an unsmear library[3] that’s worth mentioning, so I installed the attached proposed patch into the development version. [1] https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-le… [2] https://developers.google.com/time/smear [3] https://github.com/google/unsmear

1 0

Leap second announcement July 2022
by Howard Hinnant July 26, 2022

July 26, 2022

https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt There will be no leap second at the end of Dec. 2022. The leap second file expiration date should be updated prior to releasing 2022b. Howard

2 2

[PROPOSED] Use %z in vanguard form
by Paul Eggert July 22, 2022

July 22, 2022

* europe (Atlantic/Azores, Atlantic/Madeira): Add comments containing a vanguard equivalent. * ziguard.awk (get_minutes, offset_abbr): New functions. Support the special case for the Azores and Madeira. Convert to and from %z form. --- NEWS | 9 ++++++ europe | 12 ++++++-- ziguard.awk | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 102 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 4904819..33261ee 100644 --- a/NEWS +++ b/NEWS @@ -6,6 +6,7 @@ Unreleased, experimental changes Iran no longer observes DST after 2022. Rename Europe/Kiev to Europe/Kyiv. New zic -R option + Vanguard form now uses %z. Changes to future timestamps @@ -61,6 +62,14 @@ Unreleased, experimental changes Changes to build procedure + Source data in vanguard form now uses the %z notation, introduced + in release 2015f. For example, for America/Sao_Paulo vanguard + form contains the zone continuation line "-3:00 Brazil %z", which + is simpler and more reliable than the line "-3:00 Brazil -03/-02" + used in main and rearguard forms. The plan is for the main form + to use %z eventually; in the meantime maintainers of zi parsers + are encouraged to test the parsers on vanguard.zi. + 'make install' now defaults LOCALTIME to Factory not GMT, which means the default abbreviation is now "-00" not "GMT". diff --git a/europe b/europe index 0c008b4..776504d 100644 --- a/europe +++ b/europe @@ -2399,9 +2399,13 @@ Zone Europe/Lisbon -0:36:45 - LMT 1884 0:00 W-Eur WE%sT 1992 Sep 27 1:00s 1:00 EU CE%sT 1996 Mar 31 1:00u 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 2:00u # Horta MT +# Vanguard section, for zic and other parsers that support %z. +# -2:00 Port %z 1966 Apr 3 2:00 +# -1:00 Port %z 1983 Sep 25 1:00s +# -1:00 W-Eur %z 1992 Sep 27 1:00s +# Rearguard section, for parsers lacking %z; see ziguard.awk. -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 @@ -2413,11 +2417,14 @@ Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada -2:00 Port -02/-01 1966 Apr 3 2:00 -1:00 Port -01/+00 1983 Sep 25 1:00s -1:00 W-Eur -01/+00 1992 Sep 27 1:00s +# End of rearguard section. 0:00 EU WE%sT 1993 Mar 28 1:00u -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 1:00u # Funchal MT +# Vanguard section, for zic and other parsers that support %z. +# -1:00 Port %z +# Rearguard section, for parsers lacking %z; see ziguard.awk. -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 @@ -2427,6 +2434,7 @@ Zone Atlantic/Madeira -1:07:36 - LMT 1884 # Funchal -1:00 Port -01/+00 1945 Apr 21 22:00s -1:00 Port +01 1945 Aug 25 22:00s -1:00 Port -01/+00 1966 Apr 3 2:00 +# End of rearguard section. 0:00 Port WE%sT 1983 Sep 25 1:00s 0:00 EU WE%sT diff --git a/ziguard.awk b/ziguard.awk index 25de617..91f6896 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -23,6 +23,33 @@ # of the input data as best it can within the constraints of the # rearguard format. +# Given a FIELD like "-0:30", return a minute count like -30. +function get_minutes(field, \ + sign, hours, minutes) +{ + sign = field ~ /^-/ ? -1 : 1 + hours = +field + if (field ~ /:/) { + minutes = field + sub(/[^:]*:/, "", minutes) + } + return 60 * hours + sign * minutes +} + +# Given an OFFSET, which is a minute count like 300 or 330, +# return a %z-style abbreviation like "+05" or "+0530". +function offset_abbr(offset, \ + hours, minutes, sign) +{ + hours = int(offset / 60) + minutes = offset % 60 + if (minutes) { + return sprintf("%+.4d", hours * 100 + minutes); + } else { + return sprintf("%+.2d", hours) + } +} + BEGIN { dataform_type["vanguard"] = 1 dataform_type["main"] = 1 @@ -85,6 +112,16 @@ DATAFORM != "main" { } } + # If this line should differ due to Portugal benefiting from %z if supported, + # uncomment the desired version and comment out the undesired one. + if (/^#?[\t ]+-[12]:00[\t ]+Port[\t ]+[%+-]/) { + if (/%z/ == (DATAFORM == "vanguard")) { + uncomment = in_comment + } else { + comment_out = !in_comment + } + } + if (uncomment) { sub(/^#/, "") } @@ -92,6 +129,52 @@ DATAFORM != "main" { sub(/^/, "#") } + # Prefer %z in vanguard form, explicit abbreviations otherwise. + if (DATAFORM == "vanguard") { + sub(/^(Zone[\t ]+[^\t ]+)?[\t ]+[^\t ]+[\t ]+[^\t ]+[\t ]+[-+][^\t ]+/, \ + "&CHANGE-TO-%z") + sub(/-00CHANGE-TO-%z/, "-00") + sub(/[-+][^\t ]+CHANGE-TO-/, "") + } else { + if (/^[^#]*%z/) { + stdoff_column = 2 * /^Zone/ + 1 + rules_column = stdoff_column + 1 + stdoff = get_minutes($stdoff_column) + rules = $rules_column + stdabbr = offset_abbr(stdoff) + if (rules == "-") { + abbr = stdabbr + } else { + dstabbr_only = rules ~ /^[+0-9-]/ + if (dstabbr_only) { + dstoff = get_minutes(rules) + } else { + # The DST offset is normally an hour, but there are special cases. + if (rules == "Morocco" && NF == 3) { + dstoff = -60 + } else if (rules == "NBorneo") { + dstoff = 20 + } else if (((rules == "Cook" || rules == "LH") && NF == 3) \ + || (rules == "Uruguay" \ + && /[\t ](1942 Dec 14|1960|1970|1974 Dec 22)$/)) { + dstoff = 30 + } else if (rules == "Uruguay" && /[\t ]1974 Mar 10$/) { + dstoff = 90 + } else { + dstoff = 60 + } + } + dstabbr = offset_abbr(stdoff + dstoff) + if (dstabbr_only) { + abbr = dstabbr + } else { + abbr = stdabbr "/" dstabbr + } + } + sub(/%z/, abbr) + } + } + if (DATAFORM == "rearguard") { # In rearguard form, change the Japan rule line with "Sat>=8 25:00" -- 2.36.1

1 0

[PATCH] * europe: Fix a few more "Kiev"s in comments.
by Paul Eggert July 21, 2022

July 21, 2022

--- europe | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/europe b/europe index 55217a1..0c008b4 100644 --- a/europe +++ b/europe @@ -2845,18 +2845,18 @@ Zone Europe/Simferopol 2:16:24 - LMT 1880 2:00 - EET 1992 Mar 20 # Central Crimea used Moscow time 1994/1997. # -# From Paul Eggert (2022-04-18): -# The _Economist_ (1994-05-28, p 45) reports that central Crimea switched -# from Kiev to Moscow time sometime after the January 1994 elections. +# From Paul Eggert (2022-07-21): +# The _Economist_ (1994-05-28, p 45) reported that central Crimea switched +# from Kyiv to Moscow time sometime after the January 1994 elections. # Shanks (1999) says "date of change uncertain", but implies that it happened # sometime between the 1994 DST switches. Shanks & Pottenger simply say # 1994-09-25 03:00, but that can't be right. For now, guess it # changed in May. This change evidently didn't last long; see below. 2:00 C-Eur EE%sT 1994 May -# From IATA SSIM (1994/1997), which also says that Kerch is still like Kiev. +# From IATA SSIM (1994/1997), which also said that Kerch is still like Kyiv. 3:00 C-Eur MSK/MSD 1996 Mar 31 0:00s 3:00 1:00 MSD 1996 Oct 27 3:00s -# IATA SSIM (1997-09) says Crimea switched to EET/EEST. +# IATA SSIM (1997-09) said Crimea switched to EET/EEST. # Assume it happened in March by not changing the clocks. 3:00 - MSK 1997 Mar lastSun 1:00u # From Alexander Krivenyshev (2014-03-17): @@ -4078,7 +4078,7 @@ Link Europe/Istanbul Asia/Istanbul # Istanbul is in both continents. # The law documents themselves are at # http://w1.c1.rada.gov.ua/pls/zweb_n/webproc4_1?id=&pf3511=41484 -# From Vladimir in Moscow via Alois Treindl re Kiev time 1991/2 (2014-02-28): +# From Vladimir in Moscow via Alois Treindl re Kyiv time 1991/2 (2014-02-28): # First in Ukraine they changed Time zone from UTC+3 to UTC+2 with DST: # 03 25 1990 02:00 -03.00 1 Time Zone 3 with DST # 07 01 1990 02:00 -02.00 1 Time Zone 2 with DST -- 2.36.1

1 0

[PATCH 1/3] * backward: Add backward-compatibility comment.
by Paul Eggert July 21, 2022

July 21, 2022

--- backward | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/backward b/backward index a8fd620..5a86400 100644 --- a/backward +++ b/backward @@ -8,6 +8,10 @@ # also present in the file 'backzone', which has data important only # for pre-1970 timestamps and so is out of scope for tzdb proper. +# Although this file is optional and tzdb will work if you omit it by +# building with 'make BACKWARD=', in practice downstream users +# typically use this file for backward compatibility. + # Link TARGET LINK-NAME Link Africa/Nairobi Africa/Asmera Link Africa/Abidjan Africa/Timbuktu -- 2.36.1

1 2

Re: [tz] Fixing GeoNames timezone error
by dpatte July 19, 2022

July 19, 2022

I may be mistaken, but these other zones may be based on Indigenous reservations in these areas, some of which may not have used daylight saving time. ----- Original Message ----- From: Chris Walton via tz [mailto:tz@iana.org] To: "Evan Siroky" <evan.siroky(a)yahoo.com> Cc: kerry(a)shetline.com, tz(a)iana.org Sent: Tue, 19 Jul 2022 12:49:12 -0400 Subject: Re: [tz] Fixing GeoNames timezone error I mentioned earlier in this email thread that a large portion of Ontario (including the city of Barrie) is currently within the America/Nipigon boundary in Openstreetmap (OSM). I am 100% convinced the boundary is completely wrong. e.g. #1: The city of Barrie has been using daylight saving (during summer months) since at least 1930 which means it should be included within the America/Toronto boundary instead of the America/Nipigon boundary. Here are some newspaper pages containing Barrie daylight saving announcements for several different years that I picked at random: 1930: https://news.ourontario.ca/2760660/page/1835517 1946: https://news.ourontario.ca/2909650/page/13 1960: https://news.ourontario.ca/2919309/page/2280030 1970: https://news.ourontario.ca/2914181/page/2325462 1972: https://news.ourontario.ca/2917630/page/2349924 e.g. #2: I found documented proof that Prince Edward County was using daylight saving in 1970 which means it too should be moved from America/Nipigon to America/Toronto. Realistically it has probably been using daylight saving since WWII or earlier. The Kingston Whig Standard published this blurb on April 25, 1970:PICTON — Clocks go ahead one hour here Saturday night or Sunday morning, whichever you prefer, as Daylight Saving Time takes over in Prince Edward County. OSM mapper "ArcticGnome" claims to have based the OSM boundaries for America/Nipigon and America/Toronto on Shanks and Pottenger's International Atlas without realizing that much of the Shanks & Pottenger data was fake. Both myself and ArcticGnome are now pondering whether the inaccuracy of the data warrants eliminating the following zones from OSM. America/Nipigon America/Rainy_River America/Thunder_Bay America/Glace_Bay I believe that that decision should depend on whether Paul decides to continue maintaining them as dedicated zones in the TZ database. In my opinion, none of the data for these zones is trustworthy. America/Nipigon: Currently the TZ database shows that America/Nipigon adopted daylight saving in 1974. I don't have a complete history of daylight saving for Nipigon, but I did find a page from the Nipigon Gazette that clearly shows daylight saving ending for the 1972 season on October 29, 1972. https://news.ourontario.ca/npl/122271/page/2 The implication is that Nipigon has been using daylight saving since at least 1972 and therefore the data we are using for America/Nipigon is bogus. America/Rainy_River: I could not find any useful information to prove that the data for this zone is either correct or incorrect. America/Thunder_Bay: The TZ database shows that Thunder Bay and Toronto have been in sync since 1970 except for the year 1973. The database shows Thunder Bay skipped daylight saving in 1973. However, a relatively recent article in the Bayview Magazine seems to indicate that Thunder Bay did not actually skip daylight saving in 1973: http://www.bayviewmagazine.com/article/2022/03/great-springing-forward-deba… I sent an email to both the author of that article and one of the Thunder Bay archivists. In the email I asked for clarification about 1973. I will post here if I actually get a response. America/Glace_Bay: The TZ database shows Glace Bay adopted daylight saving in 1972. It is possible that this data is correct, but I am a bit skeptical. Glace Bay is a small town about 10km from Sydney. According to this document, Sydney was observing daylight saving in the year 1969: https://articles.adsabs.harvard.edu//full/1970JRASC..64..129T/0000135.000.h… There is no compelling reason to believe that Sydney would have abandoned daylight saving in 1970 and 1971. And there is no compelling reason to believe that Glace Bay would have kept its clocks out of sync with Sydney during the summers of 1970 and 1971. The truth about Glace Bay (and other communities in Cape Breton) will likely exist in the archives of the Cape Breton Post which are maintained on microfilm at the Cape Breton Regional Library in Sydney and at the Nova Scotia Archives in Halifax. -chris On Fri, 8 Jul 2022 at 05:33, Evan Siroky <evan.siroky(a)yahoo.com> wrote: I agree with Chris. I'm adding a reference to the GitHub issue that Kerry created. https://github.com/evansiroky/timezone-boundary-builder/issues/131 Evan On Friday, 8 July 2022 at 04:22:26 am GMT+2, Chris Walton via tz <tz(a)iana.org> wrote: The Nipigon/Toronto is a pet peeve of mine. It is the result of some questionable data inside Openstreetmap (OSM). Nipigon is a small township in Northern Ontario with a population of 1473 and an area of 108 square km. To put this into perspective: -Nipigon contains 0.01% of Ontario's total population. -Nipigon makes up 0.01% of Ontario's total land area. Inside OSM, somebody moved 73% of the land in Ontario into the America/Nipigon timezone. It was done with about 120 separate changesets between February and June of 2020. Some of the changesets have no source; others list "Shanks" as a reference. After following this mailing list for 15 years, I am very skeptical of the work published by Shanks, but I am in no position to prove it is wrong. I am also skeptical that anybody travelling directly by car from Windsor to Montreal (post 1970) would have had to pass through multiple time zone regions. The OSM relations are listed below. Note that if you click on the OSM links, the colour orange is used for both inner and outer boundaries thus the inner polygons are "holes" or "excluded areas". Without shading, it is not always simple to recognize this. The relations are large and may take some time to load in your browser. OSM America/Toronto relation: Includes most of Quebec and most urban centres in Ontario. Area: 1,546,844.1 square km. https://www.openstreetmap.org/relation/6483867#map=5/53.592/-73.135 OSM America/Nipigon relation: Includes most rural areas of Ontario east of 90°W Also includes a few populated centers such as Sarnia (pop: 72,047) and Barrie (pop: 147,829). Area: 787,493.2 square km. https://www.openstreetmap.org/relation/6498592#map=6/45.982/-81.573 >From a daylight saving standpoint, both zones have been the same since 1974. It would be very helpful if somebody could accurately determine when Barrie and Sarnia started using daylight saving (without using Shanks or OSM as a reference). -chris On Thu, 7 Jul 2022 at 15:11, Kerry Shetline via tz <tz(a)iana.org> wrote:I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues. For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area. I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point. > Evan Siroky <evan.siroky(a)yahoo.com> writes: > > Hello, > I'm the maintainer of?https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. > Evan

1 0