- tz - lists.iana.org

Converting cities to tz identifiers (tangent)
by John Hawkinson Feb. 26, 2018

Feb. 26, 2018

This is a bit of a rambling tangent, so sorry. I recently had to find tz zones for ~100 American cities, and the process did not go quite as smoothly as I had expected. I figured that a review of theory.html and tz-link.html would tell me the best way to do this, and it didn't really work out that way. The result was that I found myself just reading the "northamererica" file and knocking out the states that were unambiguous, and then checking the rest against timeanddate.com or time.is. It seems wrong that this appeared to be the easiest approach at this scale, so I wonder what others would suggest (with the benefit of hindsight). And then, in most cases, converting the zones via "backward" to the "US/Eastern" American political because doing so seemed more "stable." * I was expecting theory.html to give me a little more guidance on the "right" way to do this. As best as I can tell, the "right" (no pun intended) answer is that I should geolocate each city to longitude/latitude (using some unspecified resource, which seems fine), then use one of the datasets or tools at https://data.iana.org/time-zones/tz-link.html#boundaries to convert those locations to zones. This seemed a bit much. * I was also a little surprised to not find someone with a handy list of United States states and territory mappings to tz identifiers (for those cases where the state/territory/district uniquely mapped to a tzid). Other than the comments in "northamerica" (which are not quite as structured as one might like, but are pretty good). * Then I was faced with the question of what the most stable identifier to use was. For instance, take Boston, Massachusetts. I could record it as America/New_York, or as US/Eastern. For instance, at some point in the future, either Boston or New York might exit the Eastern time zone. Cases: Case 1: If that New York exited and Boston didn't, picking US/Eastern would clearly be the more stable choice. Case 2: And if Boston exited and New York didn't, it wouldn't matter which I chose, I'd have to update my mapping when Boston moved. Case 3: If New York and Boston both exited US/Eastern and went the same way, then America/New_York would be the better choice. Case 4: If New York and Boston both exited US/Eastern and did different things, it's not clear which is the better choice, but similar to Case 2. Lather rinse repeat for 50 states + some territories and DC. My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice. (Both Massachusetts and Florida seem to have current proposals to depart US/Eastern and America/New_York.) * So, I'm curious if this anecdote triggers any reactions. Did I miss an obvious way to address this more simply? Is it horrible to have made use of third party websites that lack any sort of auditable authority but are probably correct anyhow. Is this just not a problem that people have to solve with any frequency? Does someone (Paul?) want to convince me that it's Wrong to use the "backward" zones, for the narrow (but common) case of United States of America cities? Thanks for any thoughts. --jhawk(a)mit.edu John Hawkinson

17 32

Need to update Kansas City, MO
by Kevin DeCapite Feb. 25, 2018

Feb. 25, 2018

I would like to propose a change to the database to account for Kansas City, Missouri, USA as having not observed DST between 1946 - 1965. Please see the source book referenced in the link (page 87 in the actual printed pages, standard PDF is the best way to view it): https://archive.org/details/time-changes-in-usa-1966 <https://archive.org/details/time-changes-in-usa-1966> I can also confirm the accuracy of at least this piece of information through testimony. What are the procedures for formally proposing, reviewing & accepting/rejecting such changes? Thank you. --- Kevin DeCapite kevin(a)decapite.net 562.355.8222

2 1

AP & WFLA-TV: Florida House OKs bill asking to skip Daylight Saving Time
by Vance, Frank Feb. 24, 2018

Feb. 24, 2018

http://wfla.com/2018/02/14/florida-house-oks-bill-asking-to-skip-daylight-s… "The [Florida] House voted 103-11 to approve the bill to ask Congress to let Florida remain in Daylight Saving Time all year, meaning while the rest of the Eastern United States sets their clocks back in the fall, Florida wouldn't." Regards, F

7 8

SGT abbreviation is missing from the IANA tz database
by Lu, Can Feb. 21, 2018

Feb. 21, 2018

Hi Paul, Hope you're well. By way of introduction, this is Can, working as a software developer in BAML. We noticed that Asia/Singapore had its SGT abbreviation dropped in tzdb 2017, and the reason being is that the zone abbreviation doesn't correspond to any real-world usage. But it's actually not entirely true, SGT is very commonly used in Singapore and it's also a standard abbreviation for Singapore time. Please refer to: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations and https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations Wondering if it's possible to add SGT back to IANA db as I believe this change will cause breaks to other libraries rely on it. (We're using pytz for python development). I am happy to discuss and appreciate any thoughts you may have on it. Thanks, Can ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.

4 4

[PROPOSED] Parallelize the main part of 'make to2050new.tzs'
by Paul Eggert Feb. 21, 2018

Feb. 21, 2018

This improves real-time performance of 'make -j4 to2050new.tzs' by a factor of about 3.5 (from 120 s to 34 s) on my old 4-core desktop, which runs Fedora 27 x86-64 atop an AMD Phenom II X4 910e. * Makefile (ZDS): New macro. ($(ZDS)): New rule. All targets are phony. ($(TZS_NEW)): Use it in a submake that is parallelized by GNU make -j. (check_links): Depend on tzdata.zi, fixing a dependency bug. * NEWS: Mention this. --- Makefile | 29 ++++++++++++++++++++--------- NEWS | 4 ++++ 2 files changed, 24 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index fc15c3e..835f34b 100644 --- a/Makefile +++ b/Makefile @@ -640,19 +640,29 @@ posix_packrat: zones: $(REDO) +# dummy.zd is not a real file; it is mentioned here only so that the +# top-level 'make' does not have a syntax error. +ZDS = dummy.zd +# Rule used only by submakes invoked by the $(TZS_NEW) rule. +# It is separate so that GNU 'make -j' can run instances in parallel. +$(ZDS): zdump + ./zdump -i -c $(TZS_YEAR) '$(wd)/'$$(expr $@ : '$.*$.zd') >$@ + $(TZS_NEW): tzdata.zi zdump zic - mkdir -p tzs.dir + rm -fr tzs.dir + mkdir tzs.dir $(zic) -d tzs.dir tzdata.zi $(AWK) '/^L/{print "Link\t" $$2 "\t" $$3}' \ tzdata.zi | LC_ALL=C sort >$@.out wd=`pwd` && \ - zones=`$(AWK) -v wd="$$wd" \ - '/^Z/{print wd "/tzs.dir/" $$2}' tzdata.zi \ - | LC_ALL=C sort` && \ - ./zdump -i -c $(TZS_YEAR) $$zones >>$@.out - sed 's,^TZ=".*tzs\.dir/,TZ=",' $@.out >$@.sed.out - rm -fr tzs.dir $@.out - mv $@.sed.out $@ + set x `$(AWK) '/^Z/{print "tzs.dir/" $$2 ".zd"}' tzdata.zi \ + | LC_ALL=C sort -t . -k 2,2` && \ + shift && \ + ZDS=$$* && \ + $(MAKE) wd="$$wd" TZS_YEAR=$(TZS_YEAR) ZDS="$$ZDS" $$ZDS && \ + sed 's,^TZ=".*tzs\.dir/,TZ=",' $$ZDS >>$@.out + rm -fr tzs.dir + mv $@.out $@ # If $(TZS) does not already exist (e.g., old-format tarballs), create it. # If it exists but 'make check_tzs' fails, a maintainer should inspect the @@ -730,7 +740,7 @@ check_sorted: backward backzone iso3166.tab zone.tab zone1970.tab $(AWK) '/^[^#]/ $(CHECK_CC_LIST)' zone1970.tab | \ LC_ALL=C sort -cu -check_links: checklinks.awk $(TDATA_TO_CHECK) +check_links: checklinks.awk $(TDATA_TO_CHECK) tzdata.zi $(AWK) -f checklinks.awk $(TDATA_TO_CHECK) $(AWK) -f checklinks.awk tzdata.zi @@ -964,3 +974,4 @@ zic.o: private.h tzfile.h version.h .PHONY: public right_only right_posix signatures signatures_version .PHONY: tarballs tarballs_version typecheck .PHONY: zonenames zones +.PHONY: $(ZDS) diff --git a/NEWS b/NEWS index 3d18e89..1d2827e 100644 --- a/NEWS +++ b/NEWS @@ -79,6 +79,10 @@ Unreleased, experimental changes already can use vanguard.zi; in this respect, current tzcode is bleeding-edge. + The Makefile should now be safe for parallelized builds, and 'make + -j to2050new.tzs' is now much faster on a multiprocoessor host + with GNU Make. + When built with -DSUPPRESS_TZDIR, the tzcode library no longer prepends TZDIR/ to file names that do not begin with '/'. This is not recommended for general use, due to its security implications. -- 2.14.3

1 0

timezone history of Uruguay
by Jeremie Bonjour Feb. 20, 2018

Feb. 20, 2018

I submitted this information because it is not correct on the iana. org website. Greetings! Source: http://www.armada.mil.uy/ContenidosPDFs/sohma/web/almanaque/almanaque_2018.… Army Force of Uruguay http://www.armada.mil.uy .:Armada Nacional - Marina de Uruguay:.<http://www.armada.mil.uy/> www.armada.mil.uy Embarcación demorada La Armada Nacional, a través del Centro Coordinador de Búsqueda y Rescate en el Mar (MRCC), está realizando la búsqueda de un pesquero ... Almanac 2018, page 38 [cid:4e5339c0-4b51-4184-b33a-ad63059bec3a] Saludos. Jeremie Bonjour (+598) 093 81 21 71

4 9

Sol 5000 for Opportunity
by Tim Parenti Feb. 18, 2018

Feb. 18, 2018

Today, 16 February 2018, at 01:26:20.092 UTC, it is 01:01:06 Coordinated Mars Time on Mars Sol Date 51235, which corresponds to midnight HLST (hybrid local solar time) at the beginning of mission sol 5000 for the Opportunity (MER-B) rover at its mission reference longitude. The sol will last, of course, for 24 hours 39 minutes 35.244 seconds, ending on 17 February 2018 at 02:05:55.336 UTC. Curiosity will observe its mission sol 2000 next month, reckoned in mean solar time at its landing site, from 2018-03-22 13:24:49.020 UTC to 2018-03-23 14:04:24.264 UTC. -- Tim Parenti

5 7

apply Portuguese decree of 1911-05-30
by Michael H Deckers Feb. 17, 2018

Feb. 17, 2018

The decree [http://dre.pt/pdf1sdip/1911/05/12500/23132313.pdf] of 1911-05-30, mentioned for Europe/Lisbon prescribes time zone time scales for continental Portugal, Madeira, Azores, Cabo Verde, Guinea-Bissau, São Tomé, Angola, and Moçambique. It is currently not applied to all of these locations, and its article 5 is not correctly applied: " Art. 5.º Estas disposições entrarão em vigor no instante em que, segundo o artigo 2.º, começar o dia civil 1 de [j]aneiro de 1912, devendo então todos os relogios ser adeantados ou atrasados convenientemente, conforme as alineas seguintes:"... -- These dispositions shall enter into force at the instant at which, -- according to the 2nd article, the civil day January 1, 1912 begins, -- all clocks therefore having to be advanced or set back correspondingly, -- conforming with the following sections:.... (Article 2 specifies the various time zone time scales GMT + 00 h, GMT - 02 h, etc to be used in Portugal from 1912-01-01 onward.) The following proposals contain the necessary corrections. I have also tried to indicate exactly which data are implied by the source. I see this as a small step to make the tzdb data traceable to its sources, and thus to clarify the uncertainty of tzdb data (when they are estimated, or derived from less reliable sources). The format of these indications can certainly be improved. +# [pt 1911] decree https://dre.pt/pdf1sdip/1911/05/12500/23132313.pdf of 1911-05-30 # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada - -1:54:32 - HMT 1912-01-01 # Horta Mean Time +# [pt 1911] specifies UNTIL date, time & new GMTOFF: + -1:54:32 - HMT 1912-01-01 02:00u # Horta Mean Time -2:00 Port -02/-01 1942 Apr 25 22:00s # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Atlantic/Madeira -1:07:36 - LMT 1884 # Funchal - -1:07:36 - FMT 1912-01-01 # Funchal Mean Time +# [pt 1911] specifies UNTIL date, time & new GMTOFF: + -1:07:36 - FMT 1912-01-01 01:00u # Funchal Mean Time -1:00 Port -01/+00 1942 Apr 25 22:00s # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Lisbon -0:36:45 - LMT 1884 - -0:36:45 - LMT 1912 Jan 1 # Lisbon Mean Time +# [pt 1911] specifies UNTIL date, time & unrounded old (-00:36:44.68) and new GMTOFF: + -0:36:45 - LMT 1912 Jan 1 00:00u # Lisbon Mean Time 0:00 Port WE%sT 1966 Apr 3 2:00 The correction for Europe/Lisbon is an example where I think that Paul Eggert's proposal for GMTOFF values with fractional seconds would be helpful. [pt 1911] specifies Cabo Verde to use UT - 02 h since 1912-01-01 02:00Z. Currently, tzdb has a switch to UT - 02 h in 1907 without source (Shanks by default). This switch would precede the one in [pt 1911] which appears to be unlikely (admittedly, we know from Guernsey on 1913-06-18 that such conclusions may be wrong). # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Atlantic/Cape_Verde -1:34:04 - LMT 1907 # Praia +# [pt 1911] specifies UNTIL date, time & new GMTOFF: +# Ignore [Shanks] specifying UNTIL year 1907, no date, no time. +Zone Atlantic/Cape_Verde -1:34:04 - LMT 1912-01-01 02:00u # Praia -2:00 - -02 1942 Sep # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Africa/Bissau -1:02:20 - LMT 1912 Jan 1 +# [pt 1911] specifies UNTIL date, time & new GMTOFF: +Zone Africa/Bissau -1:02:20 - LMT 1912 Jan 1 01:00u # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Sao_Tome 0:26:56 - LMT 1884 - -0:36:32 - LMT 1912 # Lisbon Mean Time +# [pt 1911] specifies UNTIL date, time & new GMTOFF: + -0:36:32 - LMT 1912-01-01 00:00u # Lisbon Mean Time 0:00 - GMT 2018 Jan 1 01:00 Note that Lisbon Mean Time as in [pt 1911] and in [Milne 1899] differs from the GMTOFF given here for it (from Shanks?). # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Macau 7:34:20 - LMT 1912 Jan 1 +# [pt 1911] specifies UNTIL date, time & new GMTOFF: +Zone Asia/Macau 7:34:20 - LMT 1911-12-31 16:00u 8:00 Macau C%sT In backzone: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Luanda 0:52:56 - LMT 1892 - 0:52:04 - LMT 1912 Jan 1 +# [pt 1911] specifies UNTIL date, time & new GMTOFF: + 0:52:04 - LMT 1911-12-31 23:00u 1:00 - WAT The decree specifies that Goa (Panaji) and Timor (Aisa/Dili) should keep the time scale of the adjacent colonies. Michael Deckers.

2 1

[PATCH 1/2] Improve use of non-ASCII symbols in commentary
by Paul Eggert Feb. 16, 2018

Feb. 16, 2018

From: Paul Eggert <eggert(a)Penguin.CS.UCLA.EDU> Go back to using °, ±, etc. in commentary. This was prompted by my recent minor cleanup change of “34°” to “34 degrees” for Uruguay commentary. As it happens, this cleanup wasn't really needed for XEmacs, and it's annoying to have to use longwinded workarounds for common symbols. * Makefile (UNUSUAL_OK_CHARSET): New macro. (OK_CHAR): Use it. (check_character_set): Check Makefile seperately, since its UNUSUAL_OK_CHARSET can be a non-SAFE_LINE now. * NEWS: Mention this. --- Makefile | 22 +++++++++++++++------- NEWS | 6 +++++- asia | 11 +++++------ australasia | 4 ++-- backzone | 6 +++--- europe | 14 +++++++------- northamerica | 5 ++--- southamerica | 2 +- zone1970.tab | 2 +- 9 files changed, 41 insertions(+), 31 deletions(-) diff --git a/Makefile b/Makefile index 47acbbd..fc15c3e 100644 --- a/Makefile +++ b/Makefile @@ -408,13 +408,19 @@ SAFE_CHARSET3= 'abcdefghijklmnopqrstuvwxyz{|}~' SAFE_CHARSET= $(SAFE_CHARSET1)$(SAFE_CHARSET2)$(SAFE_CHARSET3) SAFE_CHAR= '[]'$(SAFE_CHARSET)'-]' +# Non-ASCII non-letters that OK_CHAR allows, as these characters are +# useful in commentary. XEmacs 21.5.34 displays them correctly, +# presumably because they are Latin-1. +UNUSUAL_OK_CHARSET= °±½¾× + # OK_CHAR matches any character allowed in the distributed files. -# This is the same as SAFE_CHAR, except that multibyte letters are -# also allowed so that commentary can contain people's names and quote -# non-English sources. For non-letters the sources are limited to -# ASCII renderings for the convenience of maintainers whose text editors -# mishandle UTF-8 by default (e.g., XEmacs 21.4.22). -OK_CHAR= '[][:alpha:]'$(SAFE_CHARSET)'-]' +# This is the same as SAFE_CHAR, except that UNUSUAL_OK_CHARSET and +# multibyte letters are also allowed so that commentary can contain a +# few safe symbols and people's names and can quote non-English sources. +# Other non-letters are limited to ASCII renderings for the +# convenience of maintainers using XEmacs 21.5.34, which by default +# mishandles Unicode characters U+0100 and greater. +OK_CHAR= '[][:alpha:]$(UNUSUAL_OK_CHARSET)'$(SAFE_CHARSET)'-]' # SAFE_LINE matches a line of safe characters. # SAFE_SHARP_LINE is similar, except any OK character can follow '#'; @@ -689,8 +695,10 @@ check_character_set: $(ENCHILADA) sharp='#' && \ ! grep -Env $(SAFE_LINE) $(MANS) date.1 $(MANTXTS) \ $(MISC) $(SOURCES) $(WEB_PAGES) \ - CONTRIBUTING LICENSE Makefile README \ + CONTRIBUTING LICENSE README \ version tzdata.zi && \ + ! grep -Env $(SAFE_LINE)'|^UNUSUAL_OK_CHARSET='$(OK_CHAR)'*$$' \ + Makefile && \ ! grep -Env $(SAFE_SHARP_LINE) $(TDATA_TO_CHECK) backzone \ leapseconds yearistype.sh zone.tab && \ ! grep -Env $(OK_LINE) $(ENCHILADA); \ diff --git a/NEWS b/NEWS index b83cce9..1e2cfdf 100644 --- a/NEWS +++ b/NEWS @@ -108,6 +108,10 @@ Unreleased, experimental changes with links to many relevant legal documents. (Thanks to Tim Parenti.) + Commentary now uses some non-ASCII characters with Unicode value + less than U+0100, as they can be useful and should work even with + older editors such as XEmacs. + Release 2018c - 2018-01-22 23:00:44 -0800 @@ -1009,7 +1013,7 @@ Release 2016b - 2016-03-12 17:30:14 -0800 Comments in zone tables have been improved. (Thanks to J William Piggott.) tzselect again limits its menu comments so that menus fit on a - 24x80 alphanumeric display. + 24×80 alphanumeric display. A new web page tz-how-to.html. (Thanks to Bill Seymour.) diff --git a/asia b/asia index 63d2fb0..5c2fc50 100644 --- a/asia +++ b/asia @@ -1478,8 +1478,7 @@ Rule Japan 1950 1951 - May Sat>=1 24:00 1:00 D # From Hideyuki Suzuki (1998-11-09): # 'Tokyo' usually stands for the former location of Tokyo Astronomical -# Observatory: 139 degrees 44' 40.90" E (9h 18m 58.727s), -# 35 degrees 39' 16.0" N. +# Observatory: 139° 44' 40.90" E (9h 18m 58.727s), 35° 39' 16.0" N. # This data is from 'Rika Nenpyou (Chronological Scientific Tables) 1996' # edited by National Astronomical Observatory of Japan.... # JST (Japan Standard Time) has been used since 1888-01-01 00:00 (JST). @@ -1487,10 +1486,10 @@ Rule Japan 1950 1951 - May Sat>=1 24:00 1:00 D # From Hideyuki Suzuki (1998-11-16): # The ordinance No. 51 (1886) established "standard time" in Japan, -# which stands for the time on 135 degrees E. +# which stands for the time on 135° E. # In the ordinance No. 167 (1895), "standard time" was renamed to "central # standard time". And the same ordinance also established "western standard -# time", which stands for the time on 120 degrees E.... But "western standard +# time", which stands for the time on 120° E.... But "western standard # time" was abolished in the ordinance No. 529 (1937). In the ordinance No. # 167, there is no mention regarding for what place western standard time is # standard.... @@ -3097,9 +3096,9 @@ Zone Asia/Tashkent 4:37:11 - LMT 1924 May 2 # and is the basis for the information below. # # The 1906 transition was effective July 1 and standardized Indochina to -# Phù Liễn Observatory, legally 104 deg. 17'17" east of Paris. +# Phù Liễn Observatory, legally 104° 17' 17" east of Paris. # It's unclear whether this meant legal Paris Mean Time (00:09:21) or -# the Paris Meridian (2 deg. 20'14.03" E); the former yields 07:06:30.1333... +# the Paris Meridian (2° 20' 14.03" E); the former yields 07:06:30.1333... # and the latter 07:06:29.333... so either way it rounds to 07:06:30, # which is used below even though the modern-day Phù Liễn Observatory # is closer to 07:06:31. Abbreviate Phù Liễn Mean Time as PLMT. diff --git a/australasia b/australasia index 4f96458..c7c0ea7 100644 --- a/australasia +++ b/australasia @@ -1610,7 +1610,7 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901 # From Howie Phelps (1999-11-10), who talked to a Pitcairner via shortwave: # Betty Christian told me yesterday that their local time is the same as -# Pacific Standard Time. They used to be 1/2 hour different from us here in +# Pacific Standard Time. They used to be ½ hour different from us here in # Sacramento but it was changed a couple of years ago. @@ -1649,7 +1649,7 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901 # 12 hours and 20 minutes ahead of GMT. When New Zealand adjusted its # standard time in 1940s, Tonga had the choice of subtracting from its # local time to come on the same standard time as New Zealand or of -# advancing its time to maintain the differential of 13 degrees +# advancing its time to maintain the differential of 13° # (approximately 50 minutes ahead of New Zealand time). # # Because His Majesty King Tāufaʻāhau Tupou IV, then Crown Prince diff --git a/backzone b/backzone index cc724aa..2071110 100644 --- a/backzone +++ b/backzone @@ -409,7 +409,7 @@ Zone Asia/Bahrain 3:22:20 - LMT 1920 # Manamah # From Paul Eggert (2014-08-21): # In tomorrow's The Hindu, Nitya Menon reports that India had two civil time # zones starting in 1884, one in Bombay and one in Calcutta, and that railways -# used a third time zone based on Madras time (80 deg. 18'30" E). Also, +# used a third time zone based on Madras time (80° 18' 30" E). Also, # in 1881 Bombay briefly switched to Madras time, but switched back. See: # http://www.thehindu.com/news/cities/chennai/madras-375-when-madras-clocked-… #Zone Asia/Chennai [not enough info to complete] @@ -532,7 +532,7 @@ Zone Europe/Belfast -0:23:40 - LMT 1880 Aug 2 # Data from Joseph S. Myers # https://mm.icann.org/pipermail/tz/2013-September/019883.html # References to be added -# LMT is for Town Church, St. Peter Port, 49 degrees 27'17"N 2 degrees 32'10"W +# LMT is for Town Church, St. Peter Port, 49° 27' 17" N, 2° 32' 10" W. Zone Europe/Guernsey -0:10:09 - LMT 1913 Jun 18 0:00 GB-Eire %s 1940 Jul 2 1:00 C-Eur CE%sT 1945 May 8 @@ -566,7 +566,7 @@ Zone Europe/Isle_of_Man -0:17:55 - LMT 1883 Mar 30 0:00s # Data from Joseph S. Myers # https://mm.icann.org/pipermail/tz/2013-September/019883.html # References to be added -# LMT is for Parish Church, St. Helier, 49 degrees 11'0.57"N 2 degrees 6'24.33"W +# LMT is for Parish Church, St. Helier, 49° 11' 0.57" N, 2° 6' 24.33" W. Zone Europe/Jersey -0:08:26 - LMT 1898 Jun 11 16:00u 0:00 GB-Eire %s 1940 Jul 2 1:00 C-Eur CE%sT 1945 May 8 diff --git a/europe b/europe index 8aab26e..6bbb49d 100644 --- a/europe +++ b/europe @@ -117,8 +117,8 @@ # along the towpath within a few yards of it.' # # I have a one inch to one mile map of London and my estimate of the stone's -# position is 51 degrees 28' 30" N, 0 degrees 18' 45" W. The longitude should -# be within about +-2". The Ordnance Survey grid reference is TQ172761. +# position is 51° 28' 30" N, 0° 18' 45" W. The longitude should +# be within about ±2". The Ordnance Survey grid reference is TQ172761. # # [This yields GMTOFF = -0:01:15 for London LMT in the 18th century.] @@ -158,7 +158,7 @@ # after-hours daylight in which to pursue his research. # In 1895 he presented a paper to the Wellington Philosophical Society # that proposed a two-hour daylight-saving shift. See: -# Hudson GV. On seasonal time-adjustment in countries south of lat. 30 deg. +# Hudson GV. On seasonal time-adjustment in countries south of lat. 30°. # Transactions and Proceedings of the New Zealand Institute. 1895;28:734 # http://rsnz.natlib.govt.nz/volume/rsnz_28/rsnz_28_00_006110.html # Although some interest was expressed in New Zealand, his proposal @@ -2594,13 +2594,13 @@ Zone Europe/Kaliningrad 1:22:00 - LMT 1893 Apr # From Vladimir Karpinsky (2014-07-08): # LMT in Moscow (before Jul 3, 1916) is 2:30:17, that was defined by Moscow -# Observatory (coordinates: 55 deg. 45'29.70", 37 deg. 34'05.30").... +# Observatory (coordinates: 55° 45' 29.70", 37° 34' 05.30").... # LMT in Moscow since Jul 3, 1916 is 2:31:01 as a result of new standard. # (The info is from the book by Byalokoz ... p. 18.) # The time in St. Petersburg as capital of Russia was defined by # Pulkov observatory, near St. Petersburg. In 1916 LMT Moscow # was synchronized with LMT St. Petersburg (+30 minutes), (Pulkov observatory -# coordinates: 59 deg. 46'18.70", 30 deg. 19'40.70") so 30 deg. 19'40.70" > +# coordinates: 59° 46' 18.70", 30° 19' 40.70") so 30° 19' 40.70" > # 2h01m18.7s = 2:01:19. LMT Moscow = LMT St.Petersburg + 30m 2:01:19 + 0:30 = # 2:31:19 ... # @@ -3429,7 +3429,7 @@ Zone Atlantic/Canary -1:01:36 - LMT 1922 Mar # Las Palmas de Gran C. # three degrees, or twelve minutes of time, to the west of the # meridian of the Observatory of Stockholm". The law is dated 1878-05-31. # -# The observatory at that time had the meridian 18 degrees 03' 30" +# The observatory at that time had the meridian 18° 03' 30" # eastern longitude = 01:12:14 in time. Less 12 minutes gives the # national standard time as 01:00:14 ahead of GMT.... # @@ -3533,7 +3533,7 @@ Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 # From Alois Treindl (2013-09-11): # The Federal regulations say # https://www.admin.ch/opc/de/classified-compilation/20071096/index.html -# ... the meridian for Bern mean time ... is 7 degrees 26' 22.50". +# ... the meridian for Bern mean time ... is 7° 26' 22.50". # Expressed in time, it is 0h29m45.5s. # From Pierre-Yves Berger (2013-09-11): diff --git a/northamerica b/northamerica index dabca97..f4e38f8 100644 --- a/northamerica +++ b/northamerica @@ -424,8 +424,7 @@ Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21 # ...according to the Census Bureau, the largest city is Beulah (although # it's commonly referred to as Beulah-Hazen, with Hazen being the next # largest city in Mercer County). Google Maps places Beulah's city hall -# at 47 degrees 15' 51" N, 101 degrees 46' 40" W, which yields an offset -# of 6h47'07". +# at 47° 15' 51" N, 101° 46' 40" W, which yields an offset of 6h47'07". Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 -7:00 US M%sT 2010 Nov 7 2:00 @@ -458,7 +457,7 @@ Zone America/Denver -6:59:56 - LMT 1883 Nov 18 12:00:04 # California, northern Idaho (Benewah, Bonner, Boundary, Clearwater, # Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, Idaho county # north of the Salmon River, and the towns of Burgdorf and Warren), -# Nevada (except West Wendover), Oregon (except the northern 3/4 of +# Nevada (except West Wendover), Oregon (except the northern ¾ of # Malheur county), and Washington # From Paul Eggert (2016-08-20): diff --git a/southamerica b/southamerica index d97343e..c6c461c 100644 --- a/southamerica +++ b/southamerica @@ -1694,7 +1694,7 @@ Link America/Port_of_Spain America/Tortola # Virgin Islands (UK) # auspices of the National Institute for the Prediction of Time. It is unclear # exactly what offset was used during this period, though Ley No. 7200 of # 1920-04-23 used the Observatory of the National Meteorological Institute in -# Montevideo (S 34 deg. 54'33", W 056 deg. 12'45") as its reference meridian, +# Montevideo (34° 54' 33" S, 56° 12' 45" W) as its reference meridian, # retarding legal time by 15 minutes 9 seconds from 1920-04-30 24:00, # resulting in UT-04. Assume the corresponding LMT of UT-03:44:51 (given on # page 725 of the Proceedings of the Second Pan-American Scientific Congress, diff --git a/zone1970.tab b/zone1970.tab index a3b6b04..2d90ed7 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -12,7 +12,7 @@ # of ISO 3166 2-character country codes. See the file 'iso3166.tab'. # 2. Latitude and longitude of the zone's principal location # in ISO 6709 sign-degrees-minutes-seconds format, -# either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS, +# either ±DDMM±DDDMM or ±DDMMSS±DDDMMSS, # first latitude (+ is north), then longitude (+ is east). # 3. Zone name used in value of TZ environment variable. # Please see the theory.html file for how zone names are chosen. -- 2.14.3

2 3

models for timezones
by scs＠eskimo.com Feb. 14, 2018

Feb. 14, 2018

It gets mentioned here often enough, but there's another significant aspect of the tz database which I'm not sure is always sufficiently appreciated, and that's how significantly it extends on the old V7/SysV/Posix model of time zones. In that old model, a time zone has one offset from Greenwich/UTC, and maybe a second offset on top of that to realize "daylight saving time", and one set of rules for deciding when to transition to and from DST. (Once upon a time, that set of rules might have been limited to the pre-1987 rules for the United States, and it might have been hard-compiled into C code. With the advent of the Posix TZ environment variable definition it's at least a little bit more flexible.) But of course (and since the beginning) the tz database has expanded on that model in at least two different ways: 1. It's not limited to one "standard" and perhaps one "daylight" time per year; there can be almost arbitrarily many offsets and arbitrarily many transition dates between them. 2. Everything -- the "base" offset (not that this is even a meaningful concept any more), the alternate offsets, and the transition dates between them can vary over time. And of course the reasons for doing this were that both changes were necessary in order to accommodate the real world; the old SysV/Posix model simply couldn't cope. But this means that there's a significantly imperfect match between the tz database and any programming language or time-handling library that has any of these notions: * A timezone is primarily defined by its base offset from UTC. * It's an additional property of a timezone whether it observes DST or not. * If DST applies to a timezone, it's defined by an additional offset and a single set of rules defining when it applies. * DST always involves a positive offset from the base offset. You *might* be able to get away with a tricky and/or imperfect mapping between the tz database and a scheme that has some of those notions -- for example, the tz reference code successfully implements the C/Posix API, isdst flag and all -- but it's bound to have warts or imperfections. Everything I've said here is, I imagine, familiar and unsurprising to any regular reader of this list, but it probably bears a bit more discussion in the Theory file. I was going to suggest adding these two new bullets under "Extensions to POSIX": * The TZ database allows for considerably more variation in time per year beyond the familiar "standard" and "daylight savings" times. A time zone can have any number of variations per year, and they may have arbitrary designations, not limited to "standard" and "daylight". * The parameters defining a time zone can vary over time, reflecting the fact that this happens in the real world all the time, as legislatures continually redefine them. Whether and when a zone observes DST (or other variants), and even the zone's notional "base offset" from UTC, are variable. (Therefore it doesn't even really make sense to talk about a zone's "base offset", since it's not necessarily a single number.) But that's in the "Time and date functions" section, and easy to overlook. So maybe these words belong as a paragraph higher up, perhaps even in the initial "Scope of the tz database" section: Because the database's scope encompasses real-world timezones which have wide-ranging complexity and are always evolving, the model for describing time zones allows for considerably more variation in time per year beyond the familiar "standard" and "daylight savings" times. A time zone can have any number of variations per year, and they may have arbitrary designations, not limited to "standard" and "daylight". Furthermore, the parameters defining a time zone can vary over time. Whether and when a zone observes DST (or other variants), and even the zone's notional "base offset" from UTC, are variable. (Therefore it doesn't even really make sense to talk about a zone's "base offset", since it is not necessarily a single number.)

3 3

Recommendations for stable list of timezone ids
by Tobias Lindaaker Feb. 14, 2018

Feb. 14, 2018

I am trying to compile a flat list of all tzids in the Time Zone Database in a way such that the position of a tzid remains the same in the list even in the face of future changes to the Time Zone Database. I would like to know if anyone could provide me with some insight into how (a prefix of) such a list could be generated from any version of the Time Zone Database. Or would this be something I would have to maintain myself from release to release of the Time Zone Database? The requirements I would have for generating this list would be that given two releases of the Time Zone Database, X and Y. If X is released before Y, then the list generated from X must be a prefix of the list generated from Y (and vice versa: if Y is released before X, the list generated from Y must be a prefix of the list generated from X). A simple alphabetical ordering is obviously not going to work, since for example the addition of America/Punta_Arenas in 2017a would end up before many of the tzids that existed in versions prior. Since I don't require this to work for all historical releases, my first thought was to start from a fairly recent release (tzdata2013h) and verify that I got the same order when sorting the timezones based on their earliest rule. However the removal of tzids (such as Canada/East-Saskatchewan in tzdata2017c) made this impossible, since any removal makes it impossible to ensure that prior versions are strict prefixes. It now seems as if I would have to maintain this list myself, tracking each release of the Time Zone Database and ensure that any tzids added to the Time Zone Database are appended to my list in release order. If possible I would very much prefer to avoid this, since it requires me to release updates of my software to track the releases of the Time Zone Database, I would much rather like it if my software could rely on the Time Zone Database available from the system where it was running. Finally some background on why (I think) I need to generate this type of list of tzids: I am improving the support for storing timestamp values in a database management system (Neo4j), and would like to avoid having to store the timezone component of zoned timestamps as a (variable length) text component, but rather store it as a fixed size integer offset into a table of tzids. Thus I need such a stable list of tzids. I have tried searching the archives of this mailing list for similar questions before posting, but have not been able to find such an entry. The closest I found were a few questions on how to translate the tzids to localized names. Since I did not read through the entire archives, but only did a search, I apologise in advance if this has been asked and solved before, and hope that you will be able to direct my attention to that thread. Thank you, Tobias

8 15

Inappropriate project direction
by Stephen Colebourne Feb. 12, 2018

Feb. 12, 2018

In the last few years, the following changes have been made to the tzdb project. Each of these - added no value - had a cost that far exceeded the benefits - should not have happened 1) Removal of Zone definitions from many countries. While the Zone definitions may have been the same across different countries, it was never appropriate to merge the time-zones of multiple different countries (backzone being the result). - the change caused LMT values to be lost - downstream consumers had to change logic wrt the meaning of backzone - it was culturally insensitive to not provide a primary Zone entry for some countries 2) Removal of textual short zone names. While these names may well have been invented in some cases, the had often become de facto standards - end-users complained about the loss of textual names - downstream consumers had to change logic to handle numeric-style identifiers 3) Move to a niche archive format The main archive format was changed from the well-known and widely supported gz to the niche lz format. There was and is no justification for using a niche format on a project as important as this one. - downstream consumers need to find and use the niche format - Windows does not have proper support for the niche format 4) Negative SAVE values Despite being a known fact in tzdb since 2005, and despite being warned not to in advance, a decision to re-interpret the meaning of Ireland DST was pushed through. - downstream consumers broke - the interaction with CLDR is incompatible with negative DST - the change has no impact on actual times - even if someone thought it was broken, there are no benefits to making the change 5) Fractional seconds A desire to fix subsecond data from over 50 years ago. - downstream consumers will break - the number of people who care is vanishingly small Were recent discussions a one-off, I might be prepared to let things lie, but as can be seen, there is a pattern here. Not one of these changes has added value to the project. Not one of them has been necessary to the primary mission of recording what governments are doing to their clocks now, nor even in the last 40 years. Worse, the majority are driven by a notion that getting the data "pure" trumps all problems reported by downstream consumers. It is long past time to accept that tzdb needs to focus on the primary mission - recording current government changes in a stable, backwards compatible manner. Tinkering needs to stop. Stephen

10 15

EP vote on EU DST; afternoon gloom in Scotland
by Paul Eggert Feb. 11, 2018

Feb. 11, 2018

On Thursday, the European Parliament voted 384-152 to pass a nonbinding resolution calling for the European Commission to re-evaluate the current system of daylight saving time in Europe. An article about this and how it's entangled with European politics can be found here: Yeginsu C. Daylight saving time: what's it good for? European lawmakers ask. New York Times. 2018-02-09. https://www.nytimes.com/2018/02/09/world/europe/europe-daylight-saving.html My favorite quote is about the UK Daylight Saving Bill 2010-12. Yeginsu writes: "That bill was met with fierce resistance in places like Scotland, where residents argued that they liked the afternoon gloom just fine."

2 1

License of lzip, lzlib and pdlzip
by Antonio Diaz Diaz Feb. 11, 2018

Feb. 11, 2018

Bryan Smith wrote: > There is still a heavy copyleft (e.g., GPL) v. non-copyleft FLOSS > debate that rages on, with various people putting various values -- > from nothing to everything -- on that. lzip -- or more problematic, > it's lzlib -- is GPLv2 -- not even LGPL -- which has some asterisks > for commercial developers. I don't know the state of public domain > lzip (pdlzip), but it seems to be good enough for any decompression > (and most general compression). Thanks for your comments. I'll just add a clarification about lzip licensing. Lzip itself is GPL version 2 or later. Lzlib was also GPLv2+, but a year ago (in version 1.9) the license was changed to 2-clause BSD as you can see in lzlib's homepage[1]. There is also another BSD licensed library (libarchive) able to (de)compress lzip files and lzip-compressed tar archives. Pdlzip has a 2-clause BSD license[2]. It is maintained and fully compatible with the lzip format for both compression and decompression. [1] http://www.nongnu.org/lzip/lzlib.html [2] http://www.nongnu.org/lzip/pdlzip.html Best regards, Antonio.

1 0

Fractional seconds in zic input
by Paul Eggert Feb. 10, 2018

Feb. 10, 2018

For many years I've chafed at tzdata's lack of support for fractional seconds. We have good evidence of well-established standard-time UT offsets that were not multiples of one second; for example, the Netherlands before 1937. These can't be recorded in tzdata except as comments. Ideally tzcode would support fractional-second times and UT offsets all the way down the chain. This would mean changes to the tz binary format and to the runtime API, though, which is not something we'd do lightly, if ever. However, it's easy to change the zic spec to allow fractional seconds, and to change zic to accept and ignore the fractions, so that fractional seconds can be documented more formally in the data; this could well be useful to applications other than tzcode. Proposed patch attached, hairy sscanf format and all. This patch does not actually change the data, as we'll need time, and/or a procedure to automatically generate data compatible with zic 2018c and earlier.

17 51

tzdata source compatibility
by christos＠zoulas.com Feb. 7, 2018

Feb. 7, 2018

Hi, Here's my 5 cents to the tzdb compatibility discussion: - Things need to move forward; half-measures like "functional comments" end up hurting in the long term and create unpredictable behavior. - There are other users of the tzdata "source" so compatibility needs to be maintained for "some time". - On the other hand, we can't be held hostage forever; people who write parsers, should be able to maintain the code. Straw man proposal: 1. Create a version ChangeLog with tzdb; it should be simple: - a version number (for reference) - the release date (to guide expiration) - an explanation to what changed in the format (for parser writers) 2. Maintain two copies of the source; the current one, and the previous version in a "compat" subdirectory. Expire "compat" a year after the release of the next version. I hope this is helpful, christos

5 6

New open-source zoneinfo compiler
by Kerry Shetline Feb. 5, 2018

Feb. 5, 2018

Hi, In case this might be of use to others, I’ve posted a new project on GitHub, https://github.com/kshetline/compact-time-zone-generator <https://github.com/kshetline/compact-time-zone-generator>. This is a parser and compiler written in Java that produces output primarily meant to be used with web apps. The project also includes an Angular demo app which consumes this format of compiled time zone data. The README for the project explains more, and provides some demo links, which might help decide if this is a project that might be useful to share on the discussion list. -Kerry

2 1

[PROPOSED] Fix 0.5 s bug for Jakarta in 1923
by Paul Eggert Feb. 5, 2018

Feb. 5, 2018

* ziguard.awk: Fix bug for Asia/Jakarta: the 1923-12-31 transition was off by 0.5 s when fractional seconds were enabled. --- ziguard.awk | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/ziguard.awk b/ziguard.awk index 795b4ef..70376b7 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -38,6 +38,8 @@ BEGIN { frac["7:07:12"] = "7:07:12.5" # Asia/Jakarta before 1923 frac["7:36:42"] = "7:36:41.7" # Asia/Hong_Kong before 1904 frac["8:05:43"] = "8:05:43.2" # Asia/Shanghai before 1901 + + fract["23:47:12"] = "23:47:12.5" # Asia/Jakarta 1923-12-31 transition } /^Zone/ { zone = $2 } @@ -61,7 +63,7 @@ outfile != "main.zi" { } } - # Add or remove fractional seconds as needed. + # Add or remove fractional seconds as needed in UT offsets. f = $1 == "Zone" ? 3 : 1 for (rounded in frac) { original = frac[rounded] @@ -69,6 +71,13 @@ outfile != "main.zi" { $f = vanguard ? original : rounded } } + # Likewise for transition times. + for (rounded in fract) { + original = fract[rounded] + if ($(f + 6) == rounded || $(f + 6) == original) { + $(f + 6) = vanguard ? original : rounded + } + } } # If a Link line is followed by a Zone line for the same data, comment -- 2.14.3

1 0

[PROPOSED] Generalize data format upgrade procedure
by Paul Eggert Feb. 5, 2018

Feb. 5, 2018

* Makefile (XDST): Remove, replacing with the more-general ... (DATAFORM): ... new macro. All uses changed. (fulldata.zi, pdstdata.zi): Remove, replacing with the more-general ... (vanguard.zi, main.zi, rearguard.zi): ... new targets. All uses changed. (check_zishrink): Fix bug that caused this test to fail when PACKRATDATA was nonempty and testing vanguard or rearguard data. * NEWS, europe: Mention changes. * ziguard.awk: Handle fractional seconds as well as negative DST offsets. Rename from zidst.awk, since it now handles issues other than just DST. All uses changed. --- Makefile | 69 ++++++++++++++++++----------------------------- NEWS | 64 ++++++++++++++++++++++++++------------------ europe | 29 +++++++++----------- zidst.awk | 50 ---------------------------------- ziguard.awk | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 166 insertions(+), 135 deletions(-) delete mode 100644 zidst.awk create mode 100644 ziguard.awk diff --git a/Makefile b/Makefile index 92ddb80..659a5b0 100644 --- a/Makefile +++ b/Makefile @@ -10,25 +10,14 @@ VERSION= unknown # Email address for bug reports. BUGEMAIL= tz(a)iana.org -# To install the full data, which can contain daylight saving time -# offsets that are negative (relative to standard time), use -# XDST= full -# To install data containing only positive daylight saving time -# offsets, but otherwise as close to the full data as practical, use -# XDST= pdst -XDST= pdst -# Parsers requiring DST offsets to be positive should use the file -# pdstdata.zi, which contains almost all the data of 'africa' etc., -# except with positive DST offsets. This works around a problem that -# was discovered in January 2018 with negative DST in tests for ICU -# and OpenJDK. See: -# https://mm.icann.org/pipermail/tz/2018-January/025825.html -# https://mm.icann.org/pipermail/tz/2018-January/025822.html -# Currently the 'africa' etc. files use pdst form if comments are -# ignored, to ease transition for parsers that do not support -# negative DST offsets. This is intended to change to full form at -# some point, so that full-featured zi parsers that use the 'africa' -# files will get the full data without changing anything. +# Choose source data features. To get new features right away, use: +# DATAFORM= vanguard +# To wait a while before using new features, to give downstream users +# time to upgrade zic (the default), use: +# DATAFORM= main +# To wait even longer for new features, use: +# DATAFORM= rearguard +DATAFORM= main # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). @@ -483,8 +472,8 @@ TDATA= $(YDATA) $(NDATA) $(BACKWARD) ZONETABLES= zone1970.tab zone.tab TABDATA= iso3166.tab $(TZDATA_TEXT) $(ZONETABLES) LEAP_DEPS= leapseconds.awk leap-seconds.list -TZDATA_ZI_DEPS= zidst.awk zishrink.awk version $(TDATA) $(PACKRATDATA) -DSTDATA_ZI_DEPS= zidst.awk $(TDATA) $(PACKRATDATA) +TZDATA_ZI_DEPS= ziguard.awk zishrink.awk version $(TDATA) $(PACKRATDATA) +DSTDATA_ZI_DEPS= ziguard.awk $(TDATA) $(PACKRATDATA) DATA= $(TDATA_TO_CHECK) backzone iso3166.tab leap-seconds.list \ leapseconds yearistype.sh $(ZONETABLES) AWK_SCRIPTS= checklinks.awk checktab.awk leapseconds.awk zishrink.awk @@ -522,7 +511,7 @@ VERSION_DEPS= \ SHELL= /bin/sh all: tzselect yearistype zic zdump libtz.a $(TABDATA) \ - fulldata.zi pdstdata.zi + vanguard.zi main.zi rearguard.zi ALL: all date $(ENCHILADA) @@ -558,14 +547,14 @@ version: $(VERSION_DEPS) mv $@.out $@ # These files can be tailored by setting BACKWARD, PACKRATDATA, etc. -fulldata.zi pdstdata.zi: $(DSTDATA_ZI_DEPS) - $(AWK) -v outfile='$@' -f zidst.awk $(TDATA) $(PACKRATDATA) \ +vanguard.zi main.zi rearguard.zi: $(DSTDATA_ZI_DEPS) + $(AWK) -v outfile='$@' -f ziguard.awk $(TDATA) $(PACKRATDATA) \ >$@.out mv $@.out $@ -tzdata.zi: $(XDST)data.zi version +tzdata.zi: $(DATAFORM).zi version version=`sed 1q version` && \ LC_ALL=C $(AWK) -v version="$$version" -f zishrink.awk \ - $(XDST)data.zi >$@.out + $(DATAFORM).zi >$@.out mv $@.out $@ version.h: version @@ -747,31 +736,25 @@ check_tzs: $(TZS) $(TZS_NEW) check_web: tz-how-to.html $(VALIDATE_ENV) $(VALIDATE) $(VALIDATE_FLAGS) tz-how-to.html -# The format of the source files, either full or pdst. -# Currently they are in pdst format, but this is expected to change. -SDST = pdst - -# Check that zishrink.awk does not alter the data, and that zidst.awk -# preserves $(SDST) data. +# Check that zishrink.awk does not alter the data, and that ziguard.awk +# preserves main-format data. check_zishrink: zic leapseconds $(PACKRATDATA) $(TDATA) \ - $(XDST)data.zi tzdata.zi + $(DATAFORM).zi tzdata.zi for type in posix right; do \ - mkdir -p time_t.dir/$$type time_t.dir/$$type-$(SDST) \ + mkdir -p time_t.dir/$$type time_t.dir/$$type-t \ time_t.dir/$$type-shrunk && \ case $$type in \ right) leap='-L leapseconds';; \ *) leap=;; \ esac && \ - $(ZIC) $$leap -d time_t.dir/$$type $(XDST)data.zi && \ - $(AWK) '/^Rule/' $(XDST)data.zi | \ - $(ZIC) $$leap -d time_t.dir/$$type - $(PACKRATDATA) && \ - case $(XDST) in \ - $(SDST)) \ - $(ZIC) $$leap -d time_t.dir/$$type-$(SDST) $(TDATA) && \ + $(ZIC) $$leap -d time_t.dir/$$type $(DATAFORM).zi && \ + case $(DATAFORM) in \ + main) \ + $(ZIC) $$leap -d time_t.dir/$$type-t $(TDATA) && \ $(AWK) '/^Rule/' $(TDATA) | \ - $(ZIC) $$leap -d time_t.dir/$$type-$(SDST) \ - $(XDST)data.zi && \ - diff -r time_t.dir/$$type time_t.dir/$$type-$(SDST);; \ + $(ZIC) $$leap -d time_t.dir/$$type-t - \ + $(PACKRATDATA) && \ + diff -r time_t.dir/$$type time_t.dir/$$type-t;; \ esac && \ $(ZIC) $$leap -d time_t.dir/$$type-shrunk tzdata.zi && \ diff -r time_t.dir/$$type time_t.dir/$$type-shrunk || exit; \ diff --git a/NEWS b/NEWS index adc9814..b13c356 100644 --- a/NEWS +++ b/NEWS @@ -3,8 +3,8 @@ News for the tz database Unreleased, experimental changes Briefly: - Support zi parsers that mishandle negative DST offsets - Add fractional seconds to source data format. + Add support for vanguard and rearguard data consumers. + Add fractional seconds to source data format and to vanguard data. Changes to past time stamps @@ -16,30 +16,41 @@ Unreleased, experimental changes Changes to build procedure - The new XDST macro in the Makefile lets the installer choose - XDST=full, which allows arbitrary DST offsets in the data, or - XDST=pdst, which allows only positive DST offsets. Choosing - XDST=full is arguably more correct for Ireland, which observes - Irish Standard Time (IST, UTC+01) in summer and GMT (UTC) in - winter. Choosing XDST=pdst is better for zoneinfo parsers that do - not work well with negative DST offsets, notably OpenJDK+CLDR. - On platforms using tzcode or similar APIs, XDST should not affect - any behavior other than that depending on the tm_isdst flag. - - For now this change does not affect client-visible behavior by - default, as the Makefile defaults to XDST=pdst and uncommented - parts of the data source files contain only pdst-format data. - After a bit of time for testing, XDST=full and full-format source - files are planned to become the default, so that parsers that - support negative DST offsets can get full data without changing - their build procedures. Parsers requiring positive DST offsets - should use the new file pdstdata.zi instead of tzdata.zi or the - source files 'africa' etc.: pdstdata.zi is pdst-compatible, it is - automatically built from the data source files, and it will - continue to be pdst-compatible regardless of XDST. To get - full-format data now, use the new file fulldata.zi, which will - continue to be full-format regardless of XDST. To get the format - selected by XDST, use tzdata.zi. + The new DATAFORM macro in the Makefile lets the installer choose + among three source data formats. The idea is to lessen downstream + disruption when data formats are improved. + + * DATAFORM=vanguard installs from the latest, bleeding-edge + format. DATAFORM=main (the default) installs from the format + used in the 'africa' etc. files. DATAFORM=rearguard installs + from a trailing-edge format. Eventually, elements of today's + vanguard format should move to the main format, and similarly + the main format's features should eventually move to the + rearguard format. + + * In the current version, the main and rearguard formats are + identical and match that of 2018c, so this change does not + affect default behavior. The vanguard format contains two + features not in the main format: fractional seconds and negative + DST offsets. Fractional seconds were added in this release, + where they affect only zic input (output is unaffected). + Negative DST offsets improve support for Ireland, which uses + Irish Standard Time (IST, UTC+01) in summer and GMT (UTC) in + winter. tzcode has supported negative DST offsets for decades, + and this feature should move to the main format soon. However, + it will not move to the rearguard format for quite some time + because some downstream parsers do not support it. + + * The build procedure constructs three files vanguard.zi, main.zi, + and rearguard.zi, one for each format. The files represent the + same data as closely as the formats allow. These three files + are intended for downstream data consumers and are not + installed. Zoneinfo parsers that require positive DST offsets + should start using rearguard.zi, so that they will be unaffected + when the negative-DST feature moves from vanguard to main. + Bleeding-edge Zoneinfo parsers that support the new features + already can use vanguard.zi; in this respect, current tzcode is + bleeding-edge. Changes to code @@ -48,6 +59,7 @@ Unreleased, experimental changes zic currently rounds these fractions to the nearest integer (breaking ties to the even integer), the fractions may be useful to applications requiring more precision in historical timestamps. + This extension is currently used only in vanguard.zi. The code is a bit more portable to MS-Windows. (Thanks to Manuela Friedrich). diff --git a/europe b/europe index 76cbb5d..8aab26e 100644 --- a/europe +++ b/europe @@ -514,21 +514,19 @@ Link Europe/London Europe/Isle_of_Man # https://mm.icann.org/pipermail/tz/2018-January/025825.html # and with tests for OpenJDK: # https://mm.icann.org/pipermail/tz/2018-January/025822.html -# To work around this problem, zidst.awk translates the following data -# lines into two forms. First, fulldata.zi contains the full data, -# which includes negative DST offsets. Second, pdstdata.zi uses a -# traditional approximation for Irish time stamps after 1971-10-31 -# 02:00 UTC; although this approximation has tm_isdst flags that are -# the reverse of the full data, its UTC offsets are correct and this -# suffices for ICU and OpenJDK. Although this source file currently -# has pdstdata.zi lines active and fulldata.zi lines commented out, -# this is intended to change in the near future and downstream code -# should not rely on it. +# +# To work around this problem, the build procedure can translate the +# following data into two forms, one with negative DST offsets and the +# other form with a traditional approximation for Irish time stamps +# after 1971-10-31 02:00 UTC; although this approximation has tm_isdst +# flags that are reversed, its UTC offsets are correct and this often +# suffices. This source file currently uses only positive DST +# offsets, but this is intended to change and downstream code should +# not rely on it. # # The following is like GB-Eire and EU, except with standard time in -# summer and negative daylight saving time in winter. -# This rule set is active in fulldata.zi and is commented out in -# pdstdata.zi. +# summer and negative daylight saving time in winter. It is for when +# negative DST offsets are used. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S #Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT #Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST @@ -549,10 +547,9 @@ Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 0:00 1:00 IST 1947 Nov 2 2:00s 0:00 - GMT 1948 Apr 18 2:00s 0:00 GB-Eire GMT/IST 1968 Oct 27 -# The next line is active in fulldata.zi and commented out in pdstdata.zi. +# The next line is for when negative DST offsets are used. # 1:00 Eire IST/GMT -# These three lines are active in pdstdata.zi and commented out in -# fulldata.zi. +# These three lines are for when positive DST offsets are used. 1:00 - IST 1971 Oct 31 2:00u 0:00 GB-Eire GMT/IST 1996 0:00 EU GMT/IST diff --git a/zidst.awk b/zidst.awk deleted file mode 100644 index 7885e9a..0000000 --- a/zidst.awk +++ /dev/null @@ -1,50 +0,0 @@ -# Convert tzdata source into full or positive-DST form - -# Contributed by Paul Eggert. This file is in the public domain. - -# This is not a general-purpose converter; it is designed for current tzdata. -# -# When converting to full form, the output can use negative DST offsets. -# -# When converting to positive-DST form, the output uses only positive -# DST offsets. The idea is for the output data to simulate the -# behavior of the input data as best it can within the constraints of -# positive DST offsets. -# -# In the input, lines requiring the full format are commented #[full] -# and the positive DST near-equivalents are commented #[pdst]. - -BEGIN { - dst_type["full"] = 1 - dst_type["pdst"] = 1 - - # The command line should set OUTFILE to the name of the output file, - # which should start with either "full" or "pdst". - todst = substr(outfile, 1, 4) - if (!dst_type[todst]) exit 1 -} - -/^Zone/ { zone = $2 } - -{ - in_comment = /^#/ - - # Test whether this line should differ between the full and the pdst versions. - Rule_Eire = /^#?Rule[\t ]+Eire[\t ]/ - Zone_Dublin_post_1968 \ - = (zone == "Europe/Dublin" && /^#?[\t ]+[01]:00[\t ]/ \ - && (!$(in_comment + 4) || 1968 < $(in_comment + 4))) - - # If so, uncomment the desired version and comment out the undesired one. - if (Rule_Eire || Zone_Dublin_post_1968) { - if ((Rule_Eire \ - || (Zone_Dublin_post_1968 && $(in_comment + 3) == "IST/GMT")) \ - == (todst == "full")) { - sub(/^#/, "") - } else if (/^[^#]/) { - sub(/^/, "#") - } - } -} - -{ print } diff --git a/ziguard.awk b/ziguard.awk new file mode 100644 index 0000000..795b4ef --- /dev/null +++ b/ziguard.awk @@ -0,0 +1,89 @@ +# Convert tzdata source into vanguard or rearguard form. + +# Contributed by Paul Eggert. This file is in the public domain. + +# This is not a general-purpose converter; it is designed for current tzdata. +# +# When converting to vanguard form, the output can use fractional seconds +# and negative DST offsets. +# +# When converting to rearguard form, the output omits fractional +# seconds and uses only positive DST offsets. The idea is for the +# output data to simulate the behavior of the input data as best it +# can within the constraints of the rearguard format. + +BEGIN { + dst_type["vanguard.zi"] = 1 + dst_type["main.zi"] = 1 + dst_type["rearguard.zi"] = 1 + + # The command line should set OUTFILE to the name of the output file. + if (!dst_type[outfile]) exit 1 + vanguard = outfile == "vanguard.zi" + + # List non-integer standard times more accurately if known. + # This list does not attempt to record every UT offset that is + # not an integral multiple of 1 s; it merely records those that + # do not appear to be just LMT. + frac["-5:36:13"] = "-5:36:13.3" # America/Costa_Rica before 1921 + frac["-5:07:10"] = "-5:07:10.41" # America/Jamaica before 1912 + frac["-4:16:48"] = "-4:16:48.25" # America/Cordoba etc. 1894-1920 + frac["-0:36:45"] = "-0:36:44.68" # Europe/Lisbon before 1912 + frac["-0:25:21"] = "-0:25:21.1" # Europe/Dublin 1880-1916 + frac["0:19:32"] = "0:19:32.13" # Europe/Amsterdam before 1937 + frac["1:39:49"] = "1:39:49.2" # Europe/Helsinki before 1921 + frac["2:05:09"] = "2:05:08.9" # Africa/Cairo before 1900 + frac["4:37:11"] = "4:37:10.8" # Asia/Tashkent before 1924 + frac["7:06:30"] = "7:06:30.1333" #... Asia/Ho_Chi_Minh 1906-1911 + frac["7:07:12"] = "7:07:12.5" # Asia/Jakarta before 1923 + frac["7:36:42"] = "7:36:41.7" # Asia/Hong_Kong before 1904 + frac["8:05:43"] = "8:05:43.2" # Asia/Shanghai before 1901 +} + +/^Zone/ { zone = $2 } + +outfile != "main.zi" { + in_comment = /^#/ + + # If this line should differ due to Ireland using negative DST offsets, + # uncomment the desired version and comment out the undesired one. + Rule_Eire = /^#?Rule[\t ]+Eire[\t ]/ + Zone_Dublin_post_1968 \ + = (zone == "Europe/Dublin" && /^#?[\t ]+[01]:00[\t ]/ \ + && (!$(in_comment + 4) || 1968 < $(in_comment + 4))) + if (Rule_Eire || Zone_Dublin_post_1968) { + if ((Rule_Eire \ + || (Zone_Dublin_post_1968 && $(in_comment + 3) == "IST/GMT")) \ + == vanguard) { + sub(/^#/, "") + } else if (/^[^#]/) { + sub(/^/, "#") + } + } + + # Add or remove fractional seconds as needed. + f = $1 == "Zone" ? 3 : 1 + for (rounded in frac) { + original = frac[rounded] + if ($f == rounded || $f == original) { + $f = vanguard ? original : rounded + } + } +} + +# If a Link line is followed by a Zone line for the same data, comment +# out the Link line. This can happen if backzone overrides a Link +# with a Zone. +/^Link/ { + linkline[$3] = NR +} +/^Zone/ { + sub(/^Link/, "#Link", line[linkline[$2]]) +} + +{ line[NR] = $0 } + +END { + for (i = 1; i <= NR; i++) + print line[i] +} -- 2.14.3

1 0

[PROPOSED] zic now rounds to even
by Paul Eggert Feb. 5, 2018

Feb. 5, 2018

* NEWS, zic.8: Mention this. * zic.c (gethms): Round to even instead of discarding fractional seconds. --- NEWS | 5 +++-- zic.8 | 4 +++- zic.c | 18 ++++++++++++++---- 3 files changed, 20 insertions(+), 7 deletions(-) diff --git a/NEWS b/NEWS index f00b29f..adc9814 100644 --- a/NEWS +++ b/NEWS @@ -45,8 +45,9 @@ Unreleased, experimental changes zic now accepts fractional seconds in expressions like 00:19:32.13 (the UT offset of the Netherlands from 1835 to 1937). Although - zic currently ignores these fractions, they may be useful to - applications requiring more precision in historical timestamps. + zic currently rounds these fractions to the nearest integer + (breaking ties to the even integer), the fractions may be useful + to applications requiring more precision in historical timestamps. The code is a bit more portable to MS-Windows. (Thanks to Manuela Friedrich). diff --git a/zic.8 b/zic.8 index f1fc8e2..28e4bd6 100644 --- a/zic.8 +++ b/zic.8 @@ -267,8 +267,10 @@ where hour 0 is midnight at the start of the day, and hour 24 is midnight at the end of the day. Although .I zic -currently ignores any fractional seconds, the fractions may be useful +currently rounds fractional seconds to the nearest integer +(breaking ties to the even integer), the fractions may be useful to other applications requiring greater precision. +The source format does not specify any maximum precision. Any of these forms may be followed by the letter .B w if the given time is local diff --git a/zic.c b/zic.c index 4965a10..6ad31f9 100644 --- a/zic.c +++ b/zic.c @@ -1197,7 +1197,8 @@ gethms(char const *string, char const *errstring, bool signable) { zic_t hh; int sign, mm = 0, ss = 0; - char hhx, mmx, ssx, xs; + char hhx, mmx, ssx, xr = '0', xs; + int tenths = 0; bool ok = true; if (string == NULL || *string == '\0') @@ -1209,10 +1210,18 @@ gethms(char const *string, char const *errstring, bool signable) ++string; } else sign = 1; switch (sscanf(string, - "%"SCNdZIC"%c%d%c%d%c%*1d%*[0123456789]%c", - &hh, &hhx, &mm, &mmx, &ss, &ssx, &xs)) { + "%"SCNdZIC"%c%d%c%d%c%1d%*[0]%c%*[0123456789]%c", + &hh, &hhx, &mm, &mmx, &ss, &ssx, &tenths, &xr, &xs)) { default: ok = false; break; - case 6: ok &= ssx == '.'; /* fallthrough */ + case 8: + ok = '0' <= xr && xr <= '9'; + /* fallthrough */ + case 7: + ok &= ssx == '.'; + if (ok && noise) + warning(_("fractional seconds rejected by" + " pre-2018 versions of zic")); + /* fallthrough */ case 5: ok &= mmx == ':'; /* fallthrough */ case 3: ok &= hhx == ':'; /* fallthrough */ case 1: break; @@ -1231,6 +1240,7 @@ gethms(char const *string, char const *errstring, bool signable) error(_("time overflow")); return 0; } + ss += 5 + ((ss ^ 1) & (xr == '0')) <= tenths; /* Round to even. */ if (noise && (hh > HOURSPERDAY || (hh == HOURSPERDAY && (mm != 0 || ss != 0)))) warning(_("values over 24 hours not handled by pre-2007 versions of zic")); -- 2.7.4

1 0

[PROPOSED] Fix off-by-1 error for Jamaica and T&C before 1913
by Paul Eggert Feb. 5, 2018

Feb. 5, 2018

This was discovered when checking a not-yet-published version of zic. * NEWS: Mention this. * northamerica (America/Jamaica, America/Grand_Turk): * backzone (America/Cayman): Fix rounding error. --- NEWS | 3 +++ backzone | 2 +- northamerica | 6 +++--- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index beefd39..f00b29f 100644 --- a/NEWS +++ b/NEWS @@ -11,6 +11,9 @@ Unreleased, experimental changes Enderbury and Kiritimati skipped New Year's Eve 1994, not New Year's day 1995. (Thanks to Kerry Shetline.) + Fix an off-by-1 error for pre-1913 timestamps in Jamaica and in + Turks & Caicos. + Changes to build procedure The new XDST macro in the Makefile lets the installer choose diff --git a/backzone b/backzone index 3006b27..cc724aa 100644 --- a/backzone +++ b/backzone @@ -271,7 +271,7 @@ Zone America/Aruba -4:40:24 - LMT 1912 Feb 12 # Oranjestad # Cayman Is Zone America/Cayman -5:25:32 - LMT 1890 # Georgetown - -5:07:11 - KMT 1912 Feb # Kingston Mean Time + -5:07:10 - KMT 1912 Feb # Kingston Mean Time -5:00 - EST # Canada diff --git a/northamerica b/northamerica index a014126..dabca97 100644 --- a/northamerica +++ b/northamerica @@ -3264,8 +3264,8 @@ Zone America/Tegucigalpa -5:48:52 - LMT 1921 Apr # http://www.jamaicaobserver.com/columns/The-politician-in-all-of-us_17573647 # # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Jamaica -5:07:11 - LMT 1890 # Kingston - -5:07:11 - KMT 1912 Feb # Kingston Mean Time +Zone America/Jamaica -5:07:10 - LMT 1890 # Kingston + -5:07:10 - KMT 1912 Feb # Kingston Mean Time -5:00 - EST 1974 -5:00 US E%sT 1984 -5:00 - EST @@ -3415,7 +3415,7 @@ Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre # # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Grand_Turk -4:44:32 - LMT 1890 - -5:07:11 - KMT 1912 Feb # Kingston Mean Time + -5:07:10 - KMT 1912 Feb # Kingston Mean Time -5:00 - EST 1979 -5:00 US E%sT 2015 Nov Sun>=1 2:00 -4:00 - AST 2018 Mar 11 3:00 -- 2.14.3

1 0

Pacific/Enderbury and Pacific/Kiritimati, 1995
by Kerry Shetline Feb. 4, 2018

Feb. 4, 2018

Hello, When these time zones switched sides of the International Dateline at the beginning of 1995, the tz database, viewed via zdump, shows Sunday, January 1 being skipped — Saturday December 31, 1994 being followed immediately by Monday, January 2, 1995. I found an article, however, that suggests that December 31 was the day that was skipped, so that the transition would be from Friday December 30, 1994 to Sunday January 1, 1995: https://wikitravel.org/en/Kiribati <https://wikitravel.org/en/Kiribati> I have no particular reason to believe this article is authoritative, but it did strike me odd that New Year’s Day, and a Sunday (more likely to offend some people’s religious sensibilities) would be the day that was skipped rather than Saturday. -Kerry

2 2

Fwd: Request to mention 24timezones.com under the links section
by 24tz Team Feb. 3, 2018

Feb. 3, 2018

Oops, here is the patch attached ============ Forwarded message ============ >From : 24tz Team <info(a)24timezones.com> To : "tz"<tz(a)iana.org> Date : Thu, 01 Feb 2018 13:31:14 +0200 Subject : Request to mention 24timezones.com under the links section ============ Forwarded message ============ > Greetings > > https://24timezones.com is one of the oldest time zones related websites on the web, and has helped millions of people find out the time around the globe over the past 13 years, using the tz database as its primary source. > > It would be great if you could mention us under the "Websites using recent versions of the tz database" section. Please find suggested patch attached and adjust order of complexity and fanciness accordingly :) > > Many thanks for all efforts in maintaining this database! > >

2 1

[PROPOSED] Improve commentary for pre-1920 Argentina
by Paul Eggert Feb. 1, 2018

Feb. 1, 2018

* southamerica: Coalesc comments for standard time in Argentina before 1920. --- southamerica | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/southamerica b/southamerica index e1c6590..e3684aa 100644 --- a/southamerica +++ b/southamerica @@ -202,12 +202,14 @@ Rule Arg 2008 only - Oct Sun>=15 0:00 1:00 - # It's Law No. 7,210. This change is due to a public power emergency, so for # now we'll assume it's for this year only. # -# From Paul Eggert (2014-08-09): +# From Paul Eggert (2018-01-31): # Hora de verano para la República Argentina # http://buenasiembra.com.ar/esoterismo/astrologia/hora-de-verano-de-la-repub… # says that standard time in Argentina from 1894-10-31 # to 1920-05-01 was -4:16:48.25. Go with this more-precise value -# over Shanks & Pottenger. +# over Shanks & Pottenger. It is upward compatible with Milne, who +# says Córdoba time was -4:16:48.2. + # # From Mariano Absatz (2004-06-05): # These media articles from a major newspaper mostly cover the current state: @@ -392,9 +394,6 @@ Rule Arg 2008 only - Oct Sun>=15 0:00 1:00 - # plus is that this silences a zic complaint that there's no POSIX TZ # setting for time stamps past 2038. -# From Paul Eggert (2013-02-21): -# Milne says Córdoba time was -4:16:48.2. Round to the nearest second. - # Zone NAME GMTOFF RULES FORMAT [UNTIL] # # Buenos Aires (BA), Capital Federal (CF), -- 2.14.3

1 0

Re: [tz] Will you add America/Boston?
by None Jan. 31, 2018

Jan. 31, 2018

Why exactly do you want an America/Boston? The timezone for Boston is America/ New_York. -- John Harris, Jr. <johnmh(a)splentity.com> CTO, Splentity Software

2 1