- tz - lists.iana.org

Arbitrary default system time?
by Arthur David Olson March 7, 2019

March 7, 2019

A question about current operating systems. They have differing ways of establishing a system-wide default local time zone at installation time. Are the current ways flexible enough to allow establishing a zone that's not in the database (for example, Freedonia Standard Time--FST--for a newly created country)? (If not, adding a zic option to help with the matter might be of use.) @dashdashado

2 1

Re: [tz] Israel DST in 1980 and 1984 ?
by Alois Treindl March 7, 2019

March 7, 2019

-------- Forwarded Message -------- Subject: Re: [tz] Israel DST in 1980 and 1984 ? Date: Wed, 6 Mar 2019 20:49:56 +0200 From: Isaac Starkman To: Alois Treindl <alois(a)astro.ch> Dear Alois, It is correct. Summer time was in that period in 1980 and 1984, see https://www.ynet.co.il/articles/0,7340,L-3951073,00.html You can of course read it in translation. I checked the local newspapers for that years. It started on midnight and end at 01.00 am Isaac On Wed, Mar 6, 2019 at 6:42 PM Alois Treindl <alois(a)astro.ch <mailto:alois@astro.ch>> wrote: Dear Isaac, can you comment on the validity of this document? Best regards Alois -------- Forwarded Message -------- Subject: [tz] Israel DST in 1980 and 1984 ? Date: Wed, 6 Mar 2019 17:40:19 +0100 From: Alois Treindl <alois(a)astro.ch> <mailto:alois@astro.ch> To: tz(a)iana.org <mailto:tz@iana.org> I have been pointed to this document http://www.moin.gov.il/Documents/%D7%A9%D7%A2%D7%95%D7%9F%20%D7%A7%D7%99%D7… whose authenticity and origin I cannot affirm, lacking Hebrew. It concerns the years 1980 and 1984, 2 August 1980 - 13 Sept 1980 5 May 1984 - 25 August 1984 and claims that DST was in force during those periods.

2 1

Israel DST in 1980 and 1984 ?
by Alois Treindl March 6, 2019

March 6, 2019

1 0

EU summer time heading for a mess
by Tony Finch March 6, 2019

March 6, 2019

Some states want to keep it. The discussions are in flux. The change might occur in 2020 or 2021. https://m.dw.com/en/european-parliament-set-to-end-eu-wide-daylight-savings… Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at

2 1

Pennsylvania State Rep seeking to end DST
by Matthew Donadio March 6, 2019

March 6, 2019

Not sure if this will go anywhere, but a Pennsylvania State Rep is seeking a co-sponsor to end DST in the state: https://www.legis.state.pa.us/cfdocs/legis/CSM/showMemoPublic.cfm?chamber=H… >From a quick read of the memo, it looks like he has done his homework on what it would actually take from beginning to end to get this done. --Matthew Donadio (matt(a)mxd120.com)

1 0

[IANA #1136519] America / Sao_Paulo in the Time Zone Database
by Amanda Baber via RT March 5, 2019

March 5, 2019

Hi, We've been asked to submit this message to the mailing list on a requester's behalf: === Contact Name: ricardotiellet Contact Email: rhiccarddo(a)hotmail.com Please, this case needs to be fixed: Wrong> America / Sao_Paulo Right> America / Brasilia If there is a need for disambiguation, just add a suffix: _DF = Federal District or Federal Capital so use: America / Brasilia_DF if there is any compatibility problem with graphical accentuation, Use Brasilia without an acute accent on the first i (í) https://en.wikipedia.org/wiki/Bras%C3%ADlia https://en.wikipedia.org/wiki/Brasilia Please contact me if you need. Thanks a lot. === He indicated to us that he may not check the mailing list for replies. Best regards, Amanda Baber Lead IANA Services Specialist

4 4

tzdb timezone names/identifiers and links (was: Add new timezone for Hanoi Capital, Vietnam)
by Hans-Joerg Happel March 1, 2019

March 1, 2019

Dear all, as a follow-up to the "Hanoi" thread, I've some questions regarding tzdb policies. As it is a slightly separate / more general point, I'll single that thread out from the initial "Hanoi" discussion. In particular, I'd like to understand the background of the following item (taken from https://data.iana.org/time-zones/theory.html#naming) >There should typically be at least one name for each ISO 3166-1 <https://en.wikipedia.org/wiki/ISO_3166-1> officially >assigned two-letter code for an inhabited country or territory. I initially thought this would be the reason for the "Links" of "Asia/Phnom_Penh" and "Asia/Vientiane" to "Asia/Bangkok". However, latest discussion in the "Hanoi" thread rather attributed these two aliases to backwards compatibility after prior data was moved to the backzone file. I'd assume the quoted "ISO 3166-1"-based policy could make sense for two reasons: a) Congruence of ids and decision-making bodies (i.e., countries/governments): In contrast to data stored using "Asia/Bangkok", systems/data using the "Asia/Phnom_Penh" name/link/alias/id would not need to change/re-configure in case the government of Cambodia decides to deviate from "Asia/Bangkok" at some time b) Politically: Even if tzdb names might not be intended as "names", they do surface from time to time, as with configuring time zones on a machine [1], or by applications just passing through tzdb names. I can somehow understand that this is not fully satisfactory in the Vietnam/Hanoi case right now (see below). While it is neither the intention nor the concern of tzdb to deal with this, one can argue that in practice, there is still clearly a practical impact of tzdb names/ids. So any information on the rationale for the above-quoted rule is appreciated. Also, I see there are recommendations for implementers regarding localization (e.g., reference to Unicode CLDR), but I could not find recommendations concerning the usage of tzdb names/ids/links/aliases - which, in my understanding, will be the String persisted by most applications in the end? If so, setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation. In case Vietnam would deviate from "Asia/Bangkok" in the future (by either Thai or Vietnamese decision), legacy data might need to be change to an "Asia/Hanoi" identifier. I'd be interested in pointers if this aspect was ever discussed here or is considered relevant at all. Thanks and best, Hans-Joerg ps.: as for the Vietnam case, note that the "displayName()" property in Java shows "Indochina" for most zones under discussion [2] Also Unicode CLDR translations look tricky in this case (http://st.unicode.org/cldr-apps/survey?_=en&x=r_zones) [1] E.g. https://askubuntu.com/questions/323131/setting-timezone-from-terminal/323163 points out the two options of |sudo cp /usr/share/zoneinfo/Asia/Bangkok /etc/localtime| (explicit!) or |tzselect | ..yielding the following dialogue: Please select a country whose clocks agree with yours. 1) Afghanistan 18) Israel 35) Palestine ......... 15) Indonesia 32) Nepal 49) Vietnam 16) Iran 33) Oman 50) Yemen 17) Iraq 34) Pakistan #? 49 Please select one of the following time zone regions. 1) Indochina (most areas) 2) Vietnam (south) ...which looks better, but is also not ideal from a user point-of-view... [2] Java TimeZone.getDisplayName() output for EN/DE/FR locale (Oracle JDK 1.8.0_191): Asia/Bangkok / Indochina Time Asia/Bangkok / Indochina Zeit Asia/Bangkok / Heure d'Indochine Asia/Ho_Chi_Minh / Indochina Time Asia/Ho_Chi_Minh / Indochina Zeit Asia/Ho_Chi_Minh / Heure d'Indochine Asia/Phnom_Penh / Indochina Time Asia/Phnom_Penh / Indochina Zeit Asia/Phnom_Penh / Heure d'Indochine Asia/Saigon / Indochina Time Asia/Saigon / Indochina Zeit Asia/Saigon / Heure d'Indochine Asia/Vientiane / Indochina Time Asia/Vientiane / Indochina Zeit Asia/Vientiane / Heure d'Indochine VST / Indochina Time VST / Indochina Zeit VST / Heure d'Indochine -- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/> Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142

22 105

adding LLT to the Time Zone Database
by filip Feb. 26, 2019

Feb. 26, 2019

Greetings everyone! I was told that this is the community/staff of this mailing list that i should poke if i want to add an entry into the Time Zone Database. I am working at the company Firo Solutions and we have implemented LLT(liberland time) into our systems and it all works great. However, We want to add support for LLT into several larger programming libraries some maintainers have told us that we need to get LLT/Liberland Time into your database in order to get it officially supported. Liberland is a pretty new country(2015) and the timezone is UTC+1(same as serbian). Could it be added to your database? It shouldnt be so hard i think and in iana i trust! Take Care and have a good week! Sincerely Filip

3 3

Summary document for 2/5/2019 CalConnect event
by Arthur David Olson Feb. 26, 2019

Feb. 26, 2019

A summary document for the 2/5/2019 CalConnect event is now available at... http://lists.calconnect.org/pipermail/timezonediscuss-l-calconnect.org/2019… @dashdashado

2 1

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

zic option for including data from a certain year onward
by Christopher Wong Feb. 5, 2019

Feb. 5, 2019

Hi, I think the tzdb is very good with its history. However, I would like to minimize the size and has been looking into how to achieve that. Will it be of any interest with an option in zic to include only data from a certain year onward? What is the best way? 1.? Remove the Rules and Zone entries not relevant for that year onward during the parsing. Tried this, but ended up with with some nasty warnings. 2. Make changes in writezone-function. Trying this now, but I am getting confused with types, omittype, typemap, and so on. It would be good if someone that knows the code can give me some hints if this is the right place to make such a change. BR, Christopher Wong

4 4

About time
by Arthur David Olson Feb. 2, 2019

Feb. 2, 2019

Having stumbled across a copy of the educational film "About Time," I can correct the quotations that kick off the README file; the diffs should be attached. @dashdashado

4 3

Europe/Budapest timezone
by Lev Feb. 2, 2019

Feb. 2, 2019

Dear all, I've downloaded the current time zone data from this link: https://data.iana.org/time-zones/releases/tzdata2018i.tar.gz , and compiled the time zone files with zic. For Europe/Budapest, I got this tz string: CET-1CEST,M3.5.0,M10.5.0/3 I think IMHO it should be: CET-1CEST,M3.5.0/2,M10.5.0/3 Best regards, Levente -- Levente Kovacs Senior Electronic Engineer W: http://levente.logonex.eu

4 5

Fwd: Bulletin C number 57
by Tim Parenti Feb. 1, 2019

Feb. 1, 2019

FYI, per IERS Bulletin C57, there will be no leap second on 2019-06-30. Unfortunately, NIST is affected by the partial shutdown of the US government <https://www.commerce.gov/news/blog/2018/12/shutdown-due-lapse-congressional…> which has been ongoing since 2018-12-22 00:00 -05, so most of their website is unavailable, meaning it will likely be some time before they publish an updated leap-seconds.list. But since the current NIST file doesn't expire until 2019-06-28, we've got some time before we have to deal with that. Last we had left the problem of being able to take the equivalent file directly from the IERS at https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list, some lines had been added to https://hpiers.obspm.fr/iers/bul/bulc/README on 2017-04-11, but the exact text did not make any assertions about surrounding files, and we would prefer the notice be added to leap-seconds.list itself. (There are a few other typos therein which I spotted as well.) See: https://mm.icann.org/pipermail/tz/2017-April/024990.html https://mm.icann.org/pipermail/tz/2017-April/024988.html In light of the current US/NIST situation, it would be helpful to re-energize these efforts. Happy to help Christian and others come up with something workable. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Mon, 7 Jan 2019 at 10:56 Subject: Bulletin C number 57 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 07 January 2019 Bulletin C 57 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2019. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

8 19

[calsify] Streaming info for CalConnect Public Time Zone Workshop on February 5 in Zurich, Switzerland
by David Thewlis Jan. 31, 2019

Jan. 31, 2019

The CalConnect Public Time Zone Workshop will be next Tuesday, 5 February 2019, between 1400 and 1730 Central European Time. We have made arrangements with our host, Google, to stream the CalConnect Public Time Zone Workshop <https://www.calconnect.org/events/calconnect-public-time-zone-worksjop> for any interested parties who cannot be present. (The workshop was announced in November and we did get a few queries as to streaming.) The streaming will be done using Google Hangouts; the URL to join the stream is https://meet.google.com/qjb-zbip-cpf <https://meet.google.com/qjb-zbip-cpf>. You do have to have a google id of some sort (gmail is fine) to join the streaming. When you access the stream, your request to join will be authorized. Please do not attempt to join before 1345 CET. The workshop itself will take place between 1400-1730 CET. The inbound audio and video stream will be disabled, so this will be a one-way outbound feed. However, there is a chat function so you can ask questions via the chat. Our plan is to take periodic pauses so the chat questions can be brought up and answered. If that proves impractical we will answer the chat questions after the workshop is over, so you’ll want to include an e-mail address for a response. Dave Thewlis Here’s the original post: Please note that this is NOT an IETF event. CalConnect <http://www.calconnect.org/> will host a Public Time Zone Workshop on Tuesday afternoon, February 5th, during its conference at Google in Zürich, Switzerland <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019>. The Time Zone Workshop will be Tuesday February 5th from 13:30 to 17:30 at the Google facility <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019#location>. This workshop will be focussed on the potential impact of EU Summer Time changes and how the changes might be mitigated; please see our news release <http://www.calconnect.org/news/2018/10/30/calconnect-calls-eu-reconsider-ti…>. The workshop is open to the public but you must register in advance. There is no fee to attend the workshop. Attendees are invited to stay for a Welcome Reception following the workshop. More information will be provided as planning continues. The workshop is intended for anyone who needs to plan and prepare for this and other TZ/DST changes, in particular representatives from governments, industries affected by tz changes (travel, financial, health, device manufacturers, etc.), organizations deploying tz data, and organizations maintaining and updating tz data. Please register for this event at https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets… <https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets…>. We invite anyone who is interested in or concerned by the pending changes and how time zone change information might better be distributed and implemented to attend. Dave Thewlis -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org <http://www.calconnect.org/> | Dave.Thewlis(a)calconnect.org <mailto:Dave.Thewlis@calconnect.org> _______________________________________________ calsify mailing list calsify(a)ietf.org https://www.ietf.org/mailman/listinfo/calsify

1 0

DST ends 2040 in Oracle database
by Joachim Damm Jan. 31, 2019

Jan. 31, 2019

Hello, we found one issue in the Oracle database that DST calculation is wrong from 2040 and beyond. I create a SR at Oracle and the Oracle support told me, that this behavior is from the IANA tzdata file and not from Oracle. My question is, if this is the case, where can I find the required information? If this is not the case, please let me also know to give the information to the Oracle support. I will appreciate your feedback regarding the information from the Oracle SR team! Mit freundlichen Grüßen / Kind Regards i.A. Joachim Damm Senior Database Consultant Systems Integration [cid:image001.jpg@01CF7F53.FD0881C0] Werum IT Solutions GmbH Wulf-Werum-Str. 3, 21337 Lüneburg, Germany T +49 4131 8900-515 F +49 4131 8900-20 Joachim.Damm(a)Werum.com<mailto:Joachim.Damm@Werum.com> www.werum.com<http://www.werum.com/> Geschäftsführer / Managing Directors: Rüdiger Schlierenkämper, Richard Nagorny, Hans-Peter Subel RG Lüneburg / Court of Jurisdiction: Lüneburg, Germany Handelsregisternummer / Commercial Register: HRB 204984 USt.-IdNr. / VAT No.: DE 116 083 850 Connect with us: [cid:image006.jpg@01D4B3D4.B9323120] <https://www.linkedin.com/company/werum> [cid:image007.jpg@01D4B3D4.B9323120] <https://twitter.com/werum> [cid:image008.jpg@01D4B3D4.B9323120] <http://www.vimeo.com/werum> [cid:image009.jpg@01D4B3D4.B9323120] <https://www.youtube.com/werum>

12 23