February 2019 - tz - lists.iana.org

possible error or new zone?
by Steven Abner Feb. 25, 2019

Feb. 25, 2019

Hi, been years, please check out Asia/Dushanbe zone, either a typo or strange new zone? DST/+05/+06. Included is file I hope you find helpful. It's what helped me spot the oddity.

2 3

UTC(+00:00) 13:55 - 23/02/2019
by Rodrigo Mota Feb. 24, 2019

Feb. 24, 2019

2 1

Re: [tz] tz Digest, Vol 89, Issue 38
by KP Feb. 22, 2019

Feb. 22, 2019

Its cant! Vào 11:01, Th 6, 22 thg 2, 2019 <tz-request(a)iana.org đã viết: > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. Re: Please remove tzdata2018f (Paul Eggert) > 2. Re: Please remove tzdata2018f (Philip Paeps) > 3. Re: Please remove tzdata2018f (Marcos Passos) > 4. Re: Please remove tzdata2018f (Marcos Passos) > 5. Re: Please remove tzdata2018f (Philip Paeps) > 6. Re: Please remove tzdata2018f (Brian Inglis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Feb 2019 11:03:25 -0800 > From: Paul Eggert <eggert(a)cs.ucla.edu> > To: Ankur Rana <ankur.rana(a)ericsson.com>, "tz(a)iana.org" <tz(a)iana.org> > Cc: "Sunil A. K." <sunil.a.k(a)ericsson.com>, Nishit Khosla > <Nishit.Khosla(a)ericsson.com>, Jaspreet Singh D > <jaspreet.d.singh(a)ericsson.com> > Subject: Re: [tz] Please remove tzdata2018f > Message-ID: <1a71a103-df7c-858c-eb96-ef07221760f1(a)cs.ucla.edu> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 2/20/19 11:31 PM, Ankur Rana wrote: > > would it be possible to prevent the tzdata version 2018f from > > downloading on iana site? > > Although it would be possible I doubt whether it would be a good idea. > 2018f does work for many downstream users, and these users wouldn't > benefit by its withdrawal from publication. Besides, standard practice > should be to use the latest version, falling back on a previous version > only if there's trouble. > > > > ------------------------------ > > Message: 2 > Date: Fri, 22 Feb 2019 09:55:05 +0900 > From: "Philip Paeps" <philip(a)trouble.is> > To: "Ankur Rana" <ankur.rana(a)ericsson.com> > Cc: "Sunil A. K." <sunil.a.k(a)ericsson.com>, tz(a)iana.org, Nishit Khosla > <Nishit.Khosla(a)ericsson.com>, Jaspreet Singh D > <jaspreet.d.singh(a)ericsson.com> > Subject: Re: [tz] Please remove tzdata2018f > Message-ID: <68869755-39C8-4978-A0FF-C5209A05E76A(a)trouble.is> > Content-Type: text/plain; format=flowed > > On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote: > > While doing tzdata upgrade to version 2018f > > Note that you should really be upgrading to 2018i, which is the latest > version. > > > java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on > > line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 > > S' > > Java is known to be broken with respect to the last ten years or so of > changes to the tzdb data format. You'll need to generate "rearguard" > format data to feed to the Java updater. > > Paul also helpfully provides rearguard tarballs on his webpage > https://web.cs.ucla.edu/~eggert/tz/release/. > > You can easily generate those yourself by running make > rearguard_tarballs on the distribution from iana.org. > > > To avoid any reoccurrence of same, would it be possible to prevent the > > tzdata version 2018f from downloading on iana site? > > It seems silly to pull one release from an archive going back to 1993 > because one third-party implementation (even if it's a popular one) > cannot cope with the data format. > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Ministry of Information > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Feb 2019 22:14:52 -0300 > From: Marcos Passos <marcospassos.com(a)gmail.com> > To: Philip Paeps <philip(a)trouble.is>, Stephen Colebourne > <scolebourne(a)joda.org> > Cc: Nishit Khosla <Nishit.Khosla(a)ericsson.com>, "Sunil A. K." > <sunil.a.k(a)ericsson.com>, tz(a)iana.org, Ankur Rana > <ankur.rana(a)ericsson.com>, Jaspreet Singh D > <jaspreet.d.singh(a)ericsson.com> > Subject: Re: [tz] Please remove tzdata2018f > Message-ID: > <CANA3Des+0ZG=p33EndxeWhYAsysriW+2y9= > Dr6rZJE2EYzEbyQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Stephen can confirm it, but I built all versions since 2018 using JSR-310 > a few months and the result was correct. > > On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip(a)trouble.is> wrote: > > > On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote: > > > While doing tzdata upgrade to version 2018f > > > > Note that you should really be upgrading to 2018i, which is the latest > > version. > > > > > java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on > > > line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 > > > S' > > > > Java is known to be broken with respect to the last ten years or so of > > changes to the tzdb data format. You'll need to generate "rearguard" > > format data to feed to the Java updater. > > > > Paul also helpfully provides rearguard tarballs on his webpage > > https://web.cs.ucla.edu/~eggert/tz/release/. > > > > You can easily generate those yourself by running make > > rearguard_tarballs on the distribution from iana.org. > > > > > To avoid any reoccurrence of same, would it be possible to prevent the > > > tzdata version 2018f from downloading on iana site? > > > > It seems silly to pull one release from an archive going back to 1993 > > because one third-party implementation (even if it's a popular one) > > cannot cope with the data format. > > > > Philip > > > > -- > > Philip Paeps > > Senior Reality Engineer > > Ministry of Information > > >

1 0

[PROPOSED] Swaziland changed its name to Eswatini
by Paul Eggert Feb. 20, 2019

Feb. 20, 2019

This does not change time data, only a name field in iso3166.tab. * africa, backzone: Update comments accordingly. * iso3166.tab: Update SZ name. --- africa | 8 ++++---- backzone | 2 +- iso3166.tab | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/africa b/africa index 0a0f586..e4936e4 100644 --- a/africa +++ b/africa @@ -374,6 +374,9 @@ Zone Africa/Cairo 2:05:09 - LMT 1900 Oct # check the time. PRI's The World. 2015-01-30 15:15 -05. # https://www.pri.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-bet… +# Eswatini (formerly Swaziland) +# See Africa/Johannesburg. + # Gabon # See Africa/Lagos. @@ -1188,7 +1191,7 @@ Zone Africa/Johannesburg 1:52:00 - LMT 1892 Feb 8 1:30 - SAST 1903 Mar 2:00 SA SAST Link Africa/Johannesburg Africa/Maseru # Lesotho -Link Africa/Johannesburg Africa/Mbabane # Swaziland +Link Africa/Johannesburg Africa/Mbabane # Eswatini # # Marion and Prince Edward Is # scientific station since 1947 @@ -1230,9 +1233,6 @@ Zone Africa/Juba 2:06:28 - LMT 1931 2:00 Sudan CA%sT 2000 Jan 15 12:00 3:00 - EAT -# Swaziland -# See Africa/Johannesburg. - # Tanzania # See Africa/Nairobi. diff --git a/backzone b/backzone index c464ce6..380c492 100644 --- a/backzone +++ b/backzone @@ -204,7 +204,7 @@ Zone Africa/Maseru 1:50:00 - LMT 1903 Mar 2:00 1:00 SAST 1944 Mar 19 2:00 2:00 - SAST -# Swaziland +# Eswatini (formerly Swaziland) Zone Africa/Mbabane 2:04:24 - LMT 1903 Mar 2:00 - SAST diff --git a/iso3166.tab b/iso3166.tab index 98fb988..a4ff61a 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -9,8 +9,8 @@ # All text uses UTF-8 encoding. The columns of the table are as follows: # # 1. ISO 3166-1 alpha-2 country code, current as of -# ISO 3166-1 N905 (2016-11-15). See: Updates on ISO 3166-1 -# http://isotc.iso.org/livelink/livelink/Open/16944257 +# ISO 3166-1 N976 (2018-11-06). See: Updates on ISO 3166-1 +# https://isotc.iso.org/livelink/livelink/Open/16944257 # 2. The usual English name for the coded region, # chosen so that alphabetic sorting of subsets produces helpful lists. # This is not the same as the English name in the ISO 3166 tables. @@ -235,7 +235,7 @@ ST Sao Tome & Principe SV El Salvador SX St Maarten (Dutch) SY Syria -SZ Swaziland +SZ Eswatini (Swaziland) TC Turks & Caicos Is TD Chad TF French Southern & Antarctic Lands -- 2.20.1

2 2

Add new timezone for Hanoi Capital, Vietnam
by KP Feb. 20, 2019

Feb. 20, 2019

These are the reasons that I think are reasonable - After merging with Ha Tay, Hanoi (capital) is the largest province in Vietnam - +7:00 (North Vietnam and All Vietnam since 1975) timezone has been the longest unified timezone ever, compared to Asia/Saigon, Asia/Ho_Chi_Minh (modified many times) I would like to suggest adding a timezone for Hanoi or changing the name from Asia/Ho_Chi_Minh to Asia/Hanoi as the official timezone for Vietnam. Having the same article should be considered https://tz.iana.narkive.com/foJrvdQn/tz-patch-tzdata-asia-ha-noi-add-new-ti…

13 54

[PROPOSED] Check theory.html too
by Paul Eggert Feb. 19, 2019

Feb. 19, 2019

* Makefile (CHECK_WEB_PAGES): Add check_theory.html. (check_theory.html): New dependency and rule. --- Makefile | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 680f040..f88c913 100644 --- a/Makefile +++ b/Makefile @@ -493,7 +493,8 @@ MANTXTS= newctime.3.txt newstrftime.3.txt newtzset.3.txt \ COMMON= calendars CONTRIBUTING LICENSE Makefile \ NEWS README theory.html version WEB_PAGES= tz-art.html tz-how-to.html tz-link.html -CHECK_WEB_PAGES=check_tz-art.html check_tz-how-to.html check_tz-link.html +CHECK_WEB_PAGES=check_theory.html check_tz-art.html \ + check_tz-how-to.html check_tz-link.html DOCS= $(MANS) date.1 $(MANTXTS) $(WEB_PAGES) PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica @@ -806,9 +807,10 @@ check_tzs: $(TZS) $(TZS_NEW) touch $@ check_web: $(CHECK_WEB_PAGES) +check_theory.html: theory.html check_tz-art.html: tz-art.html check_tz-link.html: tz-link.html -check_tz-art.html check_tz-link.html: +check_theory.html check_tz-art.html check_tz-link.html: $(CURL) -sS --url https://validator.w3.org/nu/ -F out=gnu \ -F file=@$$(expr $@ : 'check_$.*$') -o $@.out && \ test ! -s $@.out || { cat $@.out; exit 1; } -- 2.20.1

1 0

Fwd: Re: Add new timezone for Hanoi Capital, Vietnam
by Phake Nick Feb. 19, 2019

Feb. 19, 2019

---------- Forwarded message --------- From: Phake Nick <c933103(a)gmail.com> Date: 2019-2-19 Tue 08:30 Subject: Re: [tz] Add new timezone for Hanoi Capital, Vietnam To: KP <khaiphan9x(a)gmail.com> But, take today as an example, today's sun goes up at Hanoi at 6:24am while it goes down at 5:56pm, whereas at Ho Chi Minh City it goes up at 6:12am and goes down at 6:01pm, which mean there are only like about ten minutes or so difference? On 2019-2-19 Tue 00:42, KP <khaiphan9x(a)gmail.com> wrote: > There is a difference between day and night time of 2 regions. > > Vào 20:06, Th 2, 18 thg 2, 2019 Phake Nick <c933103(a)gmail.com đã viết: > >> Could you explain what is the difference in time in Hanoi and HCMC you >> was referring to in the message? >> >> On 2019-2-18 Mon 18:21, KP <khaiphan9x(a)gmail.com> wrote: >> >>> Thank you from the above friends, so you can see that the +7 time zone >>> of Hanoi has a longer history and maybe 1 time zone is Asia/Hanoi. If you >>> live in Vietnam, you will clearly see the difference in time in Hanoi and >>> HCMC, in the future when Vietnam is more developed, it may be necessary to >>> adjust the HN and HCMC timezone. Paul Eggert, I know that there must be >>> some rules for forming time zones. However, I see many exceptions such as >>> Shanghai and Beijing, there are many other places that I have not >>> mentioned. I think Hanoi too full of criteria for a time zone, or you can >>> consider it an exception. Why not? >>> >>>>

1 0

Today's CalConnect event
by Arthur David Olson Feb. 14, 2019

Feb. 14, 2019

I listened in on today's just-concluded CalConnect event; CalConnect is "the calendaring and scheduling consortium." Just a few notes. I heard hopes for work on the time zone database, both changes (to opaque time zone identifiers) and additions (of localization information, zone boundary information, and sequencing information to track splits and mergers of time zones). There was recognition that the database work is a volunteer effort and that there's a limit to what volunteers can do. There was mention by an ISO person of ISO's effort to establish a time zone registry with requirements for advance notification of changes; the hope is that the ISO's governmental connections would help encourage compliance. A Google representative noted the company's "under construction" (no details provided) effort to develop a time zone information distribution mechanism that would allow data to get from IANA publication to in-the-field devices within a month (seen as a reasonable objective that would deal with most real-world situations). Folks saw value in having open database maintenance processes (such as the one now used by IANA) and in having multiple sources of time zone information (that can be cross-checked against one another). I trust that other folks will correct and elaborate as appropriate. @dashdashado

11 18

[PROPOSED] Internet RFC 8536 has been published
by Paul Eggert Feb. 14, 2019

Feb. 14, 2019

* Makefile, NEWS, theory.html, tz-link.html, tzfile.5, tzfile.h: Mention the new RFC. --- Makefile | 4 ++-- NEWS | 2 ++ theory.html | 4 +++- tz-link.html | 13 ++++++------- tzfile.5 | 14 ++++++++++++-- tzfile.h | 3 +++ 6 files changed, 28 insertions(+), 12 deletions(-) diff --git a/Makefile b/Makefile index 1e0a5e4..680f040 100644 --- a/Makefile +++ b/Makefile @@ -115,8 +115,8 @@ TIME_T_ALTERNATIVES = $(TIME_T_ALTERNATIVES_HEAD) $(TIME_T_ALTERNATIVES_TAIL) TIME_T_ALTERNATIVES_HEAD = int64_t TIME_T_ALTERNATIVES_TAIL = int32_t uint32_t uint64_t -# What kind of TZif data files to generate. -# (TZif is the binary time zone data format that zic generates.) +# What kind of TZif data files to generate. (TZif is the binary time +# zone data format that zic generates; see Internet RFC 8536.) # If you want only POSIX time, with time values interpreted as # seconds since the epoch (not counting leap seconds), use # REDO= posix_only diff --git a/NEWS b/NEWS index 7a84052..f5d708c 100644 --- a/NEWS +++ b/NEWS @@ -14,6 +14,8 @@ Unreleased, experimental changes Changes to documentation + Mention Internet RFC 8536 (February 2019), which documents TZif. + tz-link.html now cites tzdata-meta <https://tzdata-meta.timtimeonline.com/>. diff --git a/theory.html b/theory.html index a8da065..5ea1369 100644 --- a/theory.html +++ b/theory.html @@ -983,7 +983,9 @@ an older <code>zic</code>. constrained to be a string containing abbreviations and numeric data as described <a href="#POSIX">above</a>. The file's format is <dfn><abbr>TZif</abbr></dfn>, - a timezone information format that contains binary data. + a timezone information format that contains binary data; see + <a href="https://tools.ietf.org/html/8536">Internet + <abbr>RFC</abbr> 8536</a>. The daylight saving time rules to be used for a particular timezone are encoded in the <abbr>TZif</abbr> file; the format of the file allows <abbr>US</abbr>, diff --git a/tz-link.html b/tz-link.html index efeacd0..89ebd40 100644 --- a/tz-link.html +++ b/tz-link.html @@ -144,7 +144,9 @@ After obtaining the code and data files, see the <code>README</code> file for what to do next. The code lets you compile the <code><abbr>tz</abbr></code> source files into machine-readable binary files, one for each location. The binary files -are in a special timezone information format (<dfn><abbr>TZif</abbr></dfn>). +are in a special timezone information format (<dfn><abbr>TZif</abbr></dfn>) +specified by <a href="https://tools.ietf.org/html/8536">Internet +<abbr>RFC</abbr> 8536</a>. The code also lets you read a <abbr>TZif</abbr> file and interpret timestamps for that location.</p> @@ -282,15 +284,12 @@ along with <a href="https://tools.ietf.org/html/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for transferring time zone data by reference. The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis -mailing list</a> discusses two Internet drafts: <a +mailing list</a> discusses the Internet draft <a id="TZDIST-Geolocate" href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate">TZDIST -Geolocate Extension</a> lets a client determine its timezone +Geolocate Extension</a>, which lets a client determine its timezone from its geographic location using a <a -href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>, and -<a href="https://tools.ietf.org/html/draft-murchison-tzdist-tzif">The -Time Zone Information Format (<abbr>TZif</abbr>)</a> specifies the format of -<abbr>TZif</abbr> data.</li> +href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> Internet Calendaring and Scheduling Core Object Specification (iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) diff --git a/tzfile.5 b/tzfile.5 index bbdccfc..2f70915 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -15,7 +15,8 @@ The timezone information files used by .BR tzset (3) are typically found under a directory with a name like .IR /usr/share/zoneinfo . -These files begin with a 44-byte header containing the following fields: +These files use the format described in Internet RFC 8536. +The format begins with a 44-byte header containing the following fields: .IP * 2 The magic four-byte ASCII sequence .q "TZif" @@ -384,6 +385,15 @@ of one hour, or of 15 minutes, or of 1 minute. .BR tzset (3), .BR tzselect (8), .BR zdump (8), -.BR zic (8) +.BR zic (8). +.PP +Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). +2019 Feb. +.UR https://\:www.rfc-editor.org/\:info/\:rfc8536 +Internet RFC 8536 +.UE +.UR https://\:doi.org/\:10.17487/\:RFC8536 +doi:10.17487/RFC8536 +.UE . .\" This file is in the public domain, so clarified as of .\" 1996-06-05 by Arthur David Olson. diff --git a/tzfile.h b/tzfile.h index 27a38cc..446c8d5 100644 --- a/tzfile.h +++ b/tzfile.h @@ -33,6 +33,9 @@ #define TZDEFRULES "posixrules" #endif /* !defined TZDEFRULES */ + +/* See Internet RFC 8536 for more details about the following format. */ + /* ** Each file begins with. . . */ -- 2.20.1

2 5

Fwd: RFC 8536 on The Time Zone Information Format (TZif)
by Ken Murchison Feb. 13, 2019

Feb. 13, 2019

FYI. -------- Forwarded Message -------- Subject: RFC 8536 on The Time Zone Information Format (TZif) Date: Tue, 12 Feb 2019 12:48:24 -0800 (PST) From: rfc-editor(a)rfc-editor.org Reply-To: ietf(a)ietf.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: drafts-update-ref(a)iana.org, rfc-editor(a)rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 8536 Title: The Time Zone Information Format (TZif) Author: A. Olson, P. Eggert, K. Murchison Status: Standards Track Stream: IETF Date: February 2019 Mailbox: arthurdavidolson(a)gmail.com, eggert(a)cs.ucla.edu, murch(a)fastmailteam.com Pages: 34 Characters: 83992 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-murchison-tzdist-tzif-16.txt URL: https://www.rfc-editor.org/info/rfc8536 DOI: 10.17487/RFC8536 This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC

1 0