- tz - lists.iana.org

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. 21, 2019

Feb. 21, 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. 18, 2019

Feb. 18, 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. 13, 2019

Feb. 13, 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. 4, 2019

Feb. 4, 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

Re: [tz] DST ends 2040 in Oracle database
by Brian Inglis Jan. 31, 2019

Jan. 31, 2019

On 2019-01-31 15:25, Scott Nelson wrote: >> On Jan 31, 2019, at 4:17 PM, Brian Inglis wrote: >> Device expiration date is specified as ISO: >> https://www.ecfr.gov/cgi-bin/retrieveECFR?n=se21.8.801_118 >> "Title 21 → Chapter I → Subchapter H → Part 801 → Subpart A → §801.18 >> Title 21: Food and Drugs >> PART 801—LABELING >> Subpart A—General Labeling Provisions >> §801.18 Format of dates provided on a medical device label. >> ... >> (a) In general. Whenever the label of a medical device includes a printed >> expiration date, date of manufacture, or any other date intended to be brought >> to the attention of the user of the device, the date must be presented in the >> following format: The year, using four digits; followed by the month, using two >> digits; followed by the day, using two digits; each separated by hyphens. For >> example, January 2, 2014, must be presented as 2014-01-02. >> ... >> [78 FR 58818, Sept. 24, 2013]” > Yeah, but the exception is rather large: > (b) Exceptions. (1) A combination product that properly bears a National Drug > Code (NDC) number is not subject to the requirements of paragraph (a) of this > section. Why I restricted my statement to "Device expiration date" -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.

1 0

new NIST leap-seconds.list
by Chris Woodbury Jan. 31, 2019

Jan. 31, 2019

Thanks to Dr. Levine, NIST has a newer version of leap-seconds.list with an expiry of 28 Dec 2019. Hurrah!! (Note: I re-named it so I could see the different versions.) $ FIPS180 -f NIST_leap-seconds.3676924800.2019-01-31 -v -h Generated SHA digest matches file digest File name: NIST_leap-seconds.3676924800.2019-01-3 Original file name: leap-seconds.3676924800 Last modified: 31 Jan 2019 08:02:47 UTC Updated: 08 Jul 2016 00:00:00 UTC Expires: 28 Dec 2019 00:00:00 UTC #h 83c68138 d3650221 07dbbbcd 11fcc859 ced1106a $

1 0

Time Zone Standards
by Samah Kareem Jan. 30, 2019

Jan. 30, 2019

Hello All I want to ask about references, countries can change their time zone depending on, I want name of standards, guidelines if any. Regards Samah Kareem

3 2

Daylight saving in 2372
by Arthur David Olson Jan. 30, 2019

Jan. 30, 2019

In the "Star Trek: Deep Space Nine" episode "Paradise Lost," Captain Sisko, at Starfleet's San Francisco headquarters, mentions "19 hundred 47 hours P. S. T." Per one source*, theepisode is set in June 2372. Seems there's no daylight saving in San Francisco in 2372, but the "standard" "S" is still used. @dashdashado _ *http://www.johnstonsarchive.net/startrek/st-episodes-1.html

5 5

Bulletin C number 57
by Chris Woodbury Jan. 29, 2019

Jan. 29, 2019

Something else, as it may not be obvious. The comments and white space do not contribute to the FIPS 180 digest and they may all be edited with impunity. This is the primary reason that using the date in the comments as data is such a bad idea. There's absolutely is no way to detect any changes or tampering. So, if someone doesn't like the fact that I put in the sign of the TAI-UTC delta T (or the MJD) as comments, edit it out. (Or any line starting with # (except the timestamps) for that matter.) Paul, your "corrected" leap-seconds.list file is an attachment.

1 0

California Prop 7 approved by voters
by Alan Mintz Jan. 29, 2019

Jan. 29, 2019

Since I don't see it mentioned... In November 2018, California voters approved Proposition 7 (by a 60-40 vote), which allows the state legislature to put the state on UTC-7 (the current DST) year-round. It requires a 2/3 majority in legislature, and federal law would have to be changed to allow it as well. Apparently, Florida did something similar, and Senator Marco Rubio is pushing bills in the U.S. Senate to legalize the changes. [ http://www.capradio.org/articles/2018/11/08/californias-daylight-saving-pro… ] California Assembly Bill 7 <http://leginfo.legislature.ca.gov/faces/billStatusClient.xhtml?bill_id=2019…> was introduced in December 2018 and is currently in committee. U.S. Senate bills S. 2536 <https://www.congress.gov/bill/115th-congress/senate-bill/2536> and S. 2537 <https://www.congress.gov/bill/115th-congress/senate-bill/2537> were introduced in March 2018 and are currently in committee. -- Alan Mintz <Alan.Mintz(a)gMail.com>

1 0

Re: [tz] Bulletin C number 57
by Chris Woodbury Jan. 29, 2019

Jan. 29, 2019

Brian Inglis is correct, changes to the "white space" [newline, space, tab, and carriage return] and comments do not change FIPS 180 Secure Hash Standard (SHS) digests. And, yes, Paul Eggert is correct, I have a script that generated the file I submitted to the mailing list. However, it was written for my personal use (I generate my own leap-seconds.list file for use by NTPd on my local systems) and does decidedly *not* meet all the restrictions placed upon the code within the TZ sphere.by ICANN/IANA (and IETF?). I shudder at the thought of making it do so. First, it uses GNU's sha1sum to calculate the FIPS 180 digest string. sha1sum will return the same digest as FIPS 180 given the *same input*. The trick is getting the same input... It also uses tolower() in AWK to ease the parsing it does. (I've got a FIPS180 shell function, too.) Two, the script is really automatic. It parses Bulletin C and the USNO/MAIA's leapsec.dat file. I use AWK to pull leap-second data from leapsec.dat, convert it to NTP timestamps and TAI-UTC offsets, which, along with the data extracted from Bulletin C (which provides the update and expiry timestamps) is all the information needed to make a leap-seconds.list file. Lastly, *it literally drives me nuts* (see real mail address) that leapseconds.awk uses the date in the comments to generate "leapseconds". So, no, I don't think I'll change the comments in the file. THEY'RE COMMENTS! There is no, none, zero, nada guarantee the comments represent anything in particular. Data on the other hand, does ... we really should be using it. Maybe we should be using USNO/MAIA leapsec.dat to generate the ZIC Leap directives in the first place. The date there is not a comment. It's also easier to manipulate days than seconds (86400 time less chance of an overflow.) We could even generate our own version of leap-seconds.list for downstream users (and never worry about government shutdowns again). (A trade-off with Paris rioting?) IERS/USNO/MAIA Bulletin A (ser7.dat), series14.txt and leapsec.dat could be used instead of the the copyright files at the Paris Observatory. This is not to say I won't help. I would be glad to provide leapseconds.awk code that use the *actual data* to generate the proper ZIC Leap directives. I have several versions of leapseconds.awk that meet all hoops the TZ code must be put through. In particular, I, and Dennis Ferguson, have AWK functions that manipulate NTP timestamps into a format that can generate date strings usable for ZIC LEAP directives. Thanks to dennis.c.ferguson for the germ of an idea to start years on 1 March when calculating leap-days. BTW, Dennis, 15th century Gregorian timestamps are not proleptic. The Gregorian calendar starts on 15 Oct 1582 (14th cent). A belated and long overdue thanks to Paul for pointing out Dennis function. I apologize. Finally, this is all moot, the shutdown is over, NIST will eventually make an updated leap-seconds.list file (with the wrong update timestamp but a correct expiry). Also, Jeff Prillaman at USNO Time Services Dept. has put up an updated leap-seconds.list file at Tycho.USNO.Navy.Mil. (Thank you, Jeff !!) (The GIT backup source for leap-seconds.list (I hope)?)

1 0