- tz - lists.iana.org

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

Jan. 31, 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. 30, 2019

Jan. 30, 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

Java TZDB compiler
by Marcos Passos Jan. 26, 2019

Jan. 26, 2019

Hello, The Java TZDB compiler models transitions in terms of historical transitions and transition rules. All transition rules start one year after the latest year among the unbounded rules in the TZDB database for a given zone. Reading the docs, I found the following explanation about that extra year: Also add one more year to avoid weird case where penultimate year has odd > offset. Does anyone know what does it mean and in which cases does it occur? - Marcos

2 2

How long will the rearguard formats continue be provided?
by Pramoth Murali Jan. 25, 2019

Jan. 25, 2019

Hello! Our team utilizes a custom version of tzcode and a calendar utility that don't support negative DST offsets that was brought back in 2018e nor the 2018f fallback transactions Japan rules that were at 25:00 hour. We utilized 2018i rearguard-format version and we were able to utilize 2018i with our parsers. The 2018i announcement mentions that the rearguard is intended to be a temporary transition aid; that raises fear if we have to patch one of the upcoming tzdata releases that don't provide a rearguard with similar fixes. While we are planning to work on fixes for our timezone parsers; in order to ensure we have enough leeway for our new solutions, we would be curious to know how long will these rearguard versions (with no negative offsets) continue to be provided?

4 4

[PROPOSED] Put “North” before “Macedonia”
by Paul Eggert Jan. 25, 2019

Jan. 25, 2019

* backzone, europe, iso3166.tab: Put “North” before “Macedonia” in commentary and metadata. Might as well do it now, since the name change appears to be a done deal. This does not affect time data. --- backzone | 2 +- europe | 4 ++-- iso3166.tab | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/backzone b/backzone index 97792b1..c464ce6 100644 --- a/backzone +++ b/backzone @@ -625,7 +625,7 @@ Zone Europe/Sarajevo 1:13:40 - LMT 1884 1:00 - CET 1982 Nov 27 1:00 EU CE%sT -# Macedonia +# North Macedonia Zone Europe/Skopje 1:25:44 - LMT 1884 1:00 - CET 1941 Apr 18 23:00 1:00 C-Eur CE%sT 1945 May 8 2:00s diff --git a/europe b/europe index 587f7b0..b735a48 100644 --- a/europe +++ b/europe @@ -1855,7 +1855,7 @@ Zone Europe/Luxembourg 0:24:36 - LMT 1904 Jun 1:00 Belgium CE%sT 1977 1:00 EU CE%sT -# Macedonia +# North Macedonia # See Europe/Belgrade. # Malta @@ -3359,7 +3359,7 @@ Zone Europe/Belgrade 1:22:00 - LMT 1884 Link Europe/Belgrade Europe/Ljubljana # Slovenia Link Europe/Belgrade Europe/Podgorica # Montenegro Link Europe/Belgrade Europe/Sarajevo # Bosnia and Herzegovina -Link Europe/Belgrade Europe/Skopje # Macedonia +Link Europe/Belgrade Europe/Skopje # North Macedonia Link Europe/Belgrade Europe/Zagreb # Croatia # Slovakia diff --git a/iso3166.tab b/iso3166.tab index c2e0f8e..98fb988 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -166,7 +166,7 @@ ME Montenegro MF St Martin (French) MG Madagascar MH Marshall Islands -MK Macedonia +MK North Macedonia ML Mali MM Myanmar (Burma) MN Mongolia -- 2.17.1

1 0

Metlakatla
by TechOps Jan. 22, 2019

Jan. 22, 2019

Hello. The Metlakatla community in Alaska has decided not to change its clock back an hour starting on November 4th, 2018 (day before yesterday). They will be gmtoff=-28800 year-round. I'm told this is the list to send this information to. Any assistance or advice on getting this updated in the database is appreciated. https://www.facebook.com/141055983004923/photos/pb.141055983004923.-2207520… [image: MIC time change.jpg] - Ryan _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ AKTechOps <http://serrc.org/techops> | techops(a)serrc.org | *(907) 523-7290* *| Brian 523-7248 | Michaela 523-7258 | Nate 523-7275 | Nick 523-7291 | Ryan 523-7272 | SERRC 586-6806 |*

7 13

Re: [tz] Bulletin C number 57
by Hal Murray Jan. 20, 2019

Jan. 20, 2019

eggert(a)cs.ucla.edu said: > but I worry that the format change will also mess up downstream programs too > (notably NTP-related) Worked OK for ntpsec. There is a checksum in the file, but it only covers the non-comment digits in the file. (so white space changes are OK) The payload lines must start on column 1 - no leading white space. -- These are my opinions. I hate spam.

3 2

Conrad Maldives Rangali Island resort
by Deborah Goldsmith Jan. 20, 2019

Jan. 20, 2019

Apparently, this resort in the Maldives has its own time zone and observes GMT+06 year round, unlike Male at GMT+05. It looks like we’d need a new zone for this. Source: Internal reports and: http://conradglobalmediacenter.com/assets/CNRD/docs/FactSheets/ConradMaldiv… (search for “Local Time”) I wasn’t able to find any source contradicting this information. Apparently it’s a known issue that Maldives resort islands have their own (unofficial) time zones: https://www.timeanddate.com/time/zone/maldives At the moment, users need to find a time zone that has the same GMT offset (in this case Indian/Chagos works) and use that instead. Thanks, Debbie

11 15

Some rules in tz specification files seem to be applied (by zic) outside of their declared period of applicability
by Parsifal Herzog Jan. 19, 2019

Jan. 19, 2019

In the example shown below, copied from from tzdata2018i Africa file, the last Zone line, referencing the Namibia rule, should start at 1990 March 21 2:00 am. There are no Namibia transitions defined from that start, until 1994. However zic does create a transition using the second Namibia rule at the start time, as shown in the zdump output below. There are many other cases like this, where an UNTIL specification ends well before the next applicable rule of the following zone line. I am trying to read the zic manual page as a specification, and I do not understand why zic inserts that transition. It seems to me that either the last Zone line (SAST) would remain in effect until 1994, as there is no other transition defined, or that period is in an undefined state, as the SAST transition is not in effect after1990 March 21. Can someone correct my understanding? ------- Specification extract # RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Vanguard section, for zic and other parsers that support negative DST. Rule Namibia 1994 only - Mar 21 0:00 -1:00 WAT Rule Namibia 1994 2017 - Sep Sun>=1 2:00 0 CAT Rule Namibia 1995 2017 - Apr Sun>=1 2:00 -1:00 WAT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Windhoek 1:08:24 - LMT 1892 Feb 8 1:30 - +0130 1903 Mar 2:00 - SAST 1942 Sep 20 2:00 2:00 1:00 SAST 1943 Mar 21 2:00 2:00 - SAST 1990 Mar 21 # independence # Vanguard section, for zic and other parsers that support negative DST. 2:00 Namibia %s ------ Zicdump output: $ zdump -v -c 1892,1996 Africa/Windhoek Africa/Windhoek -9223372036854775808 = NULL Africa/Windhoek -9223372036854689408 = NULL Africa/Windhoek Sun Feb 7 22:51:35 1892 UT = Sun Feb 7 23:59:59 1892 LMT isdst=0 gmtoff=4104 Africa/Windhoek Sun Feb 7 22:51:36 1892 UT = Mon Feb 8 00:21:36 1892 +0130 isdst=0 gmtoff=5400 Africa/Windhoek Sat Feb 28 22:29:59 1903 UT = Sat Feb 28 23:59:59 1903 +0130 isdst=0 gmtoff=5400 Africa/Windhoek Sat Feb 28 22:30:00 1903 UT = Sun Mar 1 00:30:00 1903 SAST isdst=0 gmtoff=7200 Africa/Windhoek Sat Sep 19 23:59:59 1942 UT = Sun Sep 20 01:59:59 1942 SAST isdst=0 gmtoff=7200 Africa/Windhoek Sun Sep 20 00:00:00 1942 UT = Sun Sep 20 03:00:00 1942 SAST isdst=1 gmtoff=10800 Africa/Windhoek Sat Mar 20 22:59:59 1943 UT = Sun Mar 21 01:59:59 1943 SAST isdst=1 gmtoff=10800 Africa/Windhoek Sat Mar 20 23:00:00 1943 UT = Sun Mar 21 01:00:00 1943 SAST isdst=0 gmtoff=7200 Africa/Windhoek Tue Mar 20 21:59:59 1990 UT = Tue Mar 20 23:59:59 1990 SAST isdst=0 gmtoff=7200 Africa/Windhoek Tue Mar 20 22:00:00 1990 UT = Wed Mar 21 00:00:00 1990 CAT isdst=0 gmtoff=7200 <------ zic inserted the 1994 "CAT" transition. How was this chosen? Africa/Windhoek Sun Mar 20 21:59:59 1994 UT = Sun Mar 20 23:59:59 1994 CAT isdst=0 gmtoff=7200 Africa/Windhoek Sun Mar 20 22:00:00 1994 UT = Sun Mar 20 23:00:00 1994 WAT isdst=1 gmtoff=3600 <----- first applicable rule in 1994. Africa/Windhoek Sun Sep 4 00:59:59 1994 UT = Sun Sep 4 01:59:59 1994 WAT isdst=1 gmtoff=3600 Africa/Windhoek Sun Sep 4 01:00:00 1994 UT = Sun Sep 4 03:00:00 1994 CAT isdst=0 gmtoff=7200 Africa/Windhoek Sat Apr 1 23:59:59 1995 UT = Sun Apr 2 01:59:59 1995 CAT isdst=0 gmtoff=7200 Africa/Windhoek Sun Apr 2 00:00:00 1995 UT = Sun Apr 2 01:00:00 1995 WAT isdst=1 gmtoff=3600 Africa/Windhoek Sun Sep 3 00:59:59 1995 UT = Sun Sep 3 01:59:59 1995 WAT isdst=1 gmtoff=3600 Africa/Windhoek Sun Sep 3 01:00:00 1995 UT = Sun Sep 3 03:00:00 1995 CAT isdst=0 gmtoff=7200 Africa/Windhoek 9223372036854689407 = NULL Africa/Windhoek 9223372036854775807 = NULL -------

6 6

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

Jan. 19, 2019

On Tue Jan 8 01:32:04 UTC 2019, Paul Eggert wrote:> In the meantime perhaps we could forge the NIST leap-seconds.list file > (including a comment that it's a forgery and why we're doing the > forgery), and then substitute the real thing whenever it shows up. I'd > rather have a script to do that than do it by hand, though. We'd need > that script anyway if we start basing our distribution on the IERS file, > as so many users now grab the NIST file from us rather than from the NIST.Your wish is my command.... # -=*( This file is in the public domain )*=- # This NTP leap-second file was created with data obtained from # the United States Naval Observatory (USNO) MAIA FTP server. # # Find it at: <ftp://maia.usno.navy.mil/ser7/leapsec.dat> # Updated using information from IERS Bulletin C 57 (7 Jan 2019) # Found at <ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat> # # This file is not a forgery, per se, but it is created # by some one/thing other than a national metrology lab. # It is necessitated by a current US government shutdown # and the resulting lack of an NIST generated file. # # UTC is a time scale based upon standard international (SI) # seconds and derived from Temps Atomique International (TAI). # # Leap seconds are an official correction to UTC to keep it # within 0.9 seconds of UT1; yet another time standard # based upon the orientation of the earth in space. # # These data, kept in "leap-seconds.list", are used by the # Network Time Protocol daemon (NTPd) to determine when to # apply leap seconds to Coordinated Universal Time (UTC). # "leap-seconds.list" is a symbolic link to the actual # file name, leap-seconds.xxxxxxxxxx, where xxxxxxxxxx # is derived from the NTP update timestamp (below). # # Theoretically, a leap second may be positive or negative. # Realistically, negative leap seconds are unlikely to occur. # # All timestamps in this leap seconds file are encoded using the # NTP epoch. These timestamps represent the number of seconds # since 1 Jan 1900 0:00:00. This is Modified Julian Date (MJD) # 15020 and Julian Date 2415020.5. There will be an unsigned # 32-bit overflow to the second NTP era in 2036 (07 Feb 2036 # 06:28:16 UTC to be precise). # # A leap second datum consists of an NTP timestamp and the # number of seconds difference between TAI and UTC (e.g. # currently TAI-UTC is 37). UTC was established at midnight on # 1 Jan 1972 with TAI-UTC started at 10. There was no mechanism # prior to that time defining when to apply leap seconds. # # Note: the first datum in the leap-seconds.list file is *not* # a leap-second; it denotes the definition of the UTC timescale. # # Leap-seconds rules are establish in: # # International Telecommunications Union-Regulation (ITU-R) # 460-6, Annex 1, Section 2. # # <http://www.itu.int/rec/R-REC-TF.460-6-200202-I/> # # NTP Leap second files have an update time (#$). This is often # the UTC zero (0) hour time of the day when the leap second file # is built. It should be updated whenever a new IERS Bulletin C # is issued. # #$ 3755808000 # # Leap second data have a lifetime. Traditionally, this ends on # the twenty-eighth (28) day of the month six months after the # period of time described in the latest IERS Bulletin C. This # is the expiry time (#@). # #@ 3786480000 # # Leap second files have a hash, as define in NIST's FIPS 180 # Secure Hash Standard (SHS), current revision 4 (FIPS 180-4). # # FIPS Publications: <http://csrc.nist.gov/publications/fips/> # Direct Link: <http://dx.doi.org/10.6028/NIST.FIPS.180-4> # # It is based on an SHA[1] digest, created using the data # portions of the file including leap second data and the update # and expiry timestamps. All "white space" and comments are # excluded in the computation thereof. The 160-bit SHA[1] # digest polynomial are encoded in five hexadecimal grouping at # the end of the file (#h). The hash itself is NOT included in # the SHA[1]. It can also be calculated using GNU sha1sum which # generates the same 160-bit digest, given the same data, in # forty hexadecimal characters. # # NTP delta #timestamp T sign Date of Change 2272060800 10 # + : 1 Jan 1972 (MJD 41317) 2287785600 11 # + : 1 Jul 1972 (MJD 41499) 2303683200 12 # + : 1 Jan 1973 (MJD 41683) 2335219200 13 # + : 1 Jan 1974 (MJD 42048) 2366755200 14 # + : 1 Jan 1975 (MJD 42413) 2398291200 15 # + : 1 Jan 1976 (MJD 42778) 2429913600 16 # + : 1 Jan 1977 (MJD 43144) 2461449600 17 # + : 1 Jan 1978 (MJD 43509) 2492985600 18 # + : 1 Jan 1979 (MJD 43874) 2524521600 19 # + : 1 Jan 1980 (MJD 44239) 2571782400 20 # + : 1 Jul 1981 (MJD 44786) 2603318400 21 # + : 1 Jul 1982 (MJD 45151) 2634854400 22 # + : 1 Jul 1983 (MJD 45516) 2698012800 23 # + : 1 Jul 1985 (MJD 46247) 2776982400 24 # + : 1 Jan 1988 (MJD 47161) 2840140800 25 # + : 1 Jan 1990 (MJD 47892) 2871676800 26 # + : 1 Jan 1991 (MJD 48257) 2918937600 27 # + : 1 Jul 1992 (MJD 48804) 2950473600 28 # + : 1 Jul 1993 (MJD 49169) 2982009600 29 # + : 1 Jul 1994 (MJD 49534) 3029443200 30 # + : 1 Jan 1996 (MJD 50083) 3076704000 31 # + : 1 Jul 1997 (MJD 50630) 3124137600 32 # + : 1 Jan 1999 (MJD 51179) 3345062400 33 # + : 1 Jan 2006 (MJD 53736) 3439756800 34 # + : 1 Jan 2009 (MJD 54832) 3550089600 35 # + : 1 Jul 2012 (MJD 56109) 3644697600 36 # + : 1 Jul 2015 (MJD 57204) 3692217600 37 # + : 1 Jan 2017 (MJD 57754) # #h ffee5390 2e3cf253 e15b646e 01768a18 e83785c3

2 1

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

Jan. 17, 2019

On Tue Jan 8 01:32:04 UTC 2019 Paul Eggert <eggert(a)cs.ucla.edu> wrote: > In the meantime perhaps we could forge the NIST leap-seconds.list file > (including a comment that it's a forgery and why we're doing the > forgery), and then substitute the real thing whenever it shows up. I'd > rather have a script to do that than do it by hand, though. We'd need > that script anyway if we start basing our distribution on the IERS file, > as so many users now grab the NIST file from us rather than from the NIST. Your wish is my command. See attachment.

1 0

Brasil DST changes
by Dedeco Balaco Jan. 15, 2019

Jan. 15, 2019

Hello, last year, the DST automatic adjust for my recently installed system was wrong. It is a Debian 9 install. I adjusted it manually in the start and end or the period. It was not done according to what was defined by our State sometime before. Please note that it was not something done close to the change date. My friends and I looked around a bit, and we found that this change should have passed here somehow. Next year, I do not know how it will be. Who is responsible for this kind of information or update?

3 3

Notice Lead Time Tracking
by Brian Inglis Jan. 13, 2019

Jan. 13, 2019

Given some recent last minute end of year announcements, could I please suggest creating a new document to formally track metadata about every time change notice's lead time from 2019, as a basis for stats, info, distributor/vendor additions and enhancements, walls of shame, etc. as this has never yet been suggested AFAIR. I could see vendors like Apple, Google, Microsoft, Oracle dev groups adding columns to local copies to track their own responses, and using those to prod government officials to do better. The document could be a text file containing an HTML document with a table tracking: CC, announcement date[/time], effective date[/time], lead time in years-months-days [hours:minutes:seconds], tzdb release date[/time], tzdb release lead time +/- in years-months-days [hours:minutes:seconds], whether change affects STD, whether change affects DST, number of zones impacted, list of zones impacted, comments about missing details etc.; with dates[/times] in ISO formats (and perhaps also Unix format metadata attributes, allowing for JS HTML text display customization and sorting by third party users); times only specified when useful or notice is days, and times are available and accurate. If anyone has been doing this already, perhaps they could contribute their data; and anyone with interest and time could backfill data from mailing list posts. -- 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.

5 6

Bulletin C 57: No leap second
by Kurt Roeckx Jan. 7, 2019

Jan. 7, 2019

Bulletin C 57 was sent today, and contained: 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 Kurt

1 0

[tz-announce] 2018i release of tz code and data available
by Paul Eggert Jan. 5, 2019

Jan. 5, 2019

The 2018i release of the tz code and data is available. It reflects the following change, which was circulated on the tz mailing list: Briefly: São Tomé and Príncipe switches from +01 to +00 on 2019-01-01. Changes to future timestamps Due to a change in government, São Tomé and Príncipe switches back from +01 to +00 on 2019-01-01 at 02:00. (Thanks to Vadim Nasardinov and Michael Deckers.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2018i.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2018i.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2018i.tar.lz As usual, links to the latest release files are here: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 388b0a55116099360a99cc9973d75ae6ec63d939 dated 2018-12-30 11:05:43 -0800 and tagged '2018i' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 1a3d53043f20b8252f7598f547d78e7294d9e0cf1fcdd2159354d9769f824c8c8a03cef9cbb7fa579345fdb41372335117d2ef782ecd9c107dd0526e59492d9d tzcode2018i.tar.gz 6afcacb377842190648ed26f01abcf3db37aa2e7c63d8c509c29b4bc0078b7ff2d4e5375291b9f53498215b9e2f04936bc6145e2f651ae0be6d8166d8d336f6a tzdata2018i.tar.gz 1bdab8ce6a2fc17e9b9d88baa7423b44254811255c82ccce0031725cd316b0ac14a696451f98c72559186270de54e8f467afdb788b2b501427f72fb4ea49d145 tzdb-2018i.tar.lz Here are the GPG checksums for the release files::n -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwpGB4ACgkQ7ZfpDmKq fjTyAw/9EA6VzQop7iRV9GA3UQa6w4Rm/P6gJwF3gkz7hlAf39A6Tueulzzwk6F8 K2oIJQ/MlVGNw5yzkGHR2NTY1W3yhSJTKR5X4k2E5f/7vGnTf3USJx2Fs2Itolyn UoGSIRHWesr3tmbNUCT4LImfNyeW2MrW4q8yw1ZS7uZ34TMxDmJ+DTbomSPVhiMu yn3Y9KEqId6z3SsV8yjcDDd4J8B0zuh2WWrhSkPLXjCtGfHdiT9YaTo8y8Ayinwr xzofREicLEj1YX+3Hx0ErUCiWbtEzByOlkSX7CXfABI6EcaNaJzUsiHvrw7TTFoy u1rrJgarkrNj7YXX8Dj4PoAp4cIH4++AwNbZKfZp5PNRlzydKYX0APpuYUwmS5Qv yXqcvsOGHau/wkDb6ZPQwUwu5g7BmZQ42Yvp8tisoeGeCNnm3zu5cKyCMy2LRKyy dELRyxKEpOSOzjYqIl06yPGtQf4xgXh4r/zKCSS1bEBEpzTIV4BvoxB1R9x26hc1 IJwcuYEeU9NAq17Njcs5jyts4SnNfryxX8+RvwtJnxnmoTc1whaMHR8CMka11XI2 bJ1FlJCQr5dBA5M5cstLJZVkreoMp1bNLiVwCL+8cdAHWGXQ6SPUDuQYyUj+wKBp EX6dfVjrX/CYQVe65HnXiqxYJpDamGk2J4suSc4SG6EF8TVtQCw= =eLXg -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIyBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwpGB8ACgkQ7ZfpDmKq fjTMog/3YJT5eFuwlijuTDxlt+VMTaAEaDaSUfzmQhaTDuHPKVDXxCaWq+tcO4J8 gzzecRj40Xc/jZId7MREq2S3uyUu7D6tJR7kRMw8BeTYVkhf+wX4Xmfh+6bVB9bO 34GNTSK9BXoieio68AkaCziVhBy6KynKhzUS4d1sqEDUxhS7r3ir6jTiU4UGAf54 PKWh2YKYITuYww4XnseG9rQsKbVKK4GUm/e7OmV3zf5pI9lhf/TQh1XZXKFbKK70 gDmFPUDAyuiFBCxkA7YsGolAnkscVmuF301brsNg+VKPy1qgMbxY/vF0lo/f7xRw dzi8+ek6/pKCIUmVRWCsg68wUDh1j3pAh9MLT8zhMtxOc42Kh+4b1BNq0x45zVbQ 693ufcf056654Y27bCexy1JbGBNEd6UUGUv/Ou9EGrl6nfrfMSmUneqmBEnl8NY+ 6/cge/JOr+rVbmEku+nuC9kLZx63lSy4BXJ8+vv4DgzE6/3906V30+w/oJUGaImx PjE9tjm6biIWdRi6bZRdFcg0mktBEyzJuAuurX0ZRgcaNkrhNd4zw2Q3yuKDcD67 aM5wUA4JVLX5v6P+s5j5Y+B+OY4sVk8fFzev8BJX+wRulqEmchVertypir17PUSr oqRUAww6oaYwenZNE+6dN0OWtpLDdBUv7+pesiYcaJRrXDCLAA== =ttI4 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwpGCEACgkQ7ZfpDmKq fjRrfA//ZeU5yiKc9WOW9kco9zXoBvlHgqpxO3qI3ESgUxslFAIpeVA/26JRbEc8 AJaEEEfmKFNFtO0Wev8WAhRT6qayaxlR30qWlhQl73F+F4xVmTuCojf02HlzUS5B QpReCDZecEMXp3SmEHrog3gMtGtT6dbofUbFjXoJtwm8OpjXzlY1LdAwO33eiOKH SKr7r7q4dm/3ZVhdFP2b/OPqiF/ezhywAoYqxIUdglroGyCGtlHECEDyYIHAHlwT /hwRk96a3/ghQiEyVbqREzwBMWydTbeo+MptCtgpA1p1vmVLxLhY/3SUaOdEBIqC mYhDuLMy9SKIVtkLBc537RnUBWyCfX3p9XZ90q2YqcpqzxX47+55IKmZ8MeWEvgU OvPUV6kYVtWCO/7bNVz4I0XaJdK/tA1vhNyk8jXaMW4duCgZZsCDn5uD3oQCKJE4 O+QZqf7k5pGWT3NWFln4vv6/mahAeoV0OxpHpn1qdA6+CAa/DVdU5ZTcaleNsTSy lAd0Zt2UBCb/rycnckgT87RrAtvjUUVq4onHSaTmtOdBYfMLr5BKtD+UClAcudvd jb15tHpErlXpZ/02Bn1yfynd5xFndGA1Rj3xIRCV31/EY+pxYl4i8ZNc9lWvtLa8 PV9bGewU6EsFohzm5/1CnJbT/gKYoFVoYkdQ7/Bc+mtNjYIAYxM= =ehq4 -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets, this particular release's data entries are also available in a rearguard-format tarball and signature that does not contain such offsets. This is intended to be a temporary transition aid for these parsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2018i/tzdata2018i-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2018i/tzdata2018i-rearguard.tar.… with the following SHA-512 and GPG checksums: 55ec0bc2504eddc72187c80c24c80ac7a2ec4c9e5b5a4cee583dcd2f97a648b35674e1eb2e390151e689f9d4eb237615d2f0f3c64b2209672e762f0bc4c580e2 tzdata2018i-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwpGB8ACgkQ7ZfpDmKq fjT/yw/9HUQnV+LGYkiQRE840qJ02XqH5K0l2R7n9OiUKsZnI+PEg5y23bUGd4+A gWwNAvC7629m+La8yiIRMO9fdNX3qHCHAXn7eUBH9nfJLcPML4t5i8kFT+NYvXwT JuauEAHDRqVQw6s0Sjeh3wsz/4Iq0c6AOuPqYC5Nnh8OgXZUsG8sNlJfB6x2Hbfe 85UimkXX+xSizN6gMxrP4Y5adoQaJRcCkvjZLm4TwGvMOTFQLNsERtl9KeiJOD3Z qEnt03Wx+kpOK2nIepe+ZgS2TtgK1uRntiu+L7MmRPmNriegCE+SCQVZhl5Kbm4a HHORTs/97B9ec6tiNreL0lg35Z/0vKA4KUdcpBGCaylGNvXNmz4TnHWHpdOWgueD 3O8E87edCTAUvQ8rAoEcqmg6CPrr2p/gfn+96w1EBfBqVJCjsZ/6KaDhbb6/LBAr oHd3TVtHMxpxrkxGXCyZwwpHEQtdnKeWPAyyc5kKd9LqUM1YQLQhQ44aN0SBeO8n spAFJLQm03GA+1aw1ETVrid474PMLTGKQj4iOg0XY/91E/L5p+Pf15ztMBo8asie lo07vW+o0ED3N0p60EXIdZxnokm/hPLo9yqbrCGpXE6wHcSFOgiK/Q5wOahrA/y0 LVI5yJt9Bc+hHLcQnwIPQei2P50ixVVDq8k2hTiM+2PN3iIcoGY= =fOhE -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

5 10

Timezone change for Asia/Qyzylorda
by Zhanbolat Raimbekov Jan. 3, 2019

Jan. 3, 2019

Hi, Starting 21 December 2018 00:00, Qyzylorda oblast, Kazakhstan (Asia/Qyzylorda) has moved back from +6 to +5. Link: http://adilet.zan.kz/rus/docs/P1800000817 -- Zhanbolat Raimbekov, Rochester Institute of Technology '12

9 15

[PROPOSED] Cite Shanks & Pottenger better
by Paul Eggert Dec. 30, 2018

Dec. 30, 2018

* tz-link.html: Provide library URLs for Shanks and Pottenger’s now out-of-print atlases, since their publisher no longer maintains web pages. Link to ANS on these atlases as sources for much of the older tz data. Use <abbr> a bit more often. --- tz-link.html | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/tz-link.html b/tz-link.html index 4f456ef..924227a 100644 --- a/tz-link.html +++ b/tz-link.html @@ -551,8 +551,8 @@ Java</a> contains a copy of a subset of a recent Java-specific format.</li> <li><a href="https://relativedata.com/page/Time-Zone-Master">Time Zone Master</a> is a Microsoft Windows clock program that can automatically -download, compile and use <code>tz</code> releases. The Basic version -is free.</li> +download, compile and use <code><abbr>tz</abbr></code> releases. +The Basic version is free.</li> <li><a href="http://veladg.com/velaterra.html">VelaTerra</a> is a macOS program. Its developers @@ -563,10 +563,16 @@ licenses</a> to <code><abbr>tz</abbr></code> contributors.</li> <ul> <li><a href="https://www.astro.com/atlas">Time-zone Atlas</a> is Astrodienst's Web version of Shanks and Pottenger's out-of-print -time zone history atlases now published in <a +time zone history atlases +<a href="https://www.worldcat.org/oclc/468828649">for the US</a> and +<a href="https://www.worldcat.org/oclc/76950459">for the world</a>, +now published in <a href="https://astrocom.com/astrology-products/software/acs-atlas-software">software</a> form by <a href="https://astrocom.com">ACS-Starcrafts</a>. -These atlases are extensive but unreliable, as Shanks appears to have +Although these extensive atlases +<a href="https://astrologynewsservice.com/opinion/how-astrologers-contributed-to-the…">were +sources for much of the older <code><abbr>tz</abbr></code> data</a>, +they are unreliable as Shanks appears to have guessed many <abbr>UT</abbr> offsets and transitions. The atlases cite no sources and do not indicate which entries are guesswork.</li> <li><a href="https://en.wikipedia.org/wiki/HP-UX">HP-UX</a> has a database in @@ -856,14 +862,14 @@ href="https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html"><abbr title="International Earth Rotation and Reference Systems Service">IERS</abbr> Bulletins</a> contains official publications of the International Earth Rotation and Reference Systems Service, which decides when leap -seconds occur. The <code>tz</code> code and data support leap seconds +seconds occur. The <code><abbr>tz</abbr></code> code and data support leap seconds via an optional "<code>right</code>" configuration, as opposed to the default "<code>posix</code>" configuration.</li> <li><a href="https://developers.google.com/time/smear">Leap Smear</a> discusses how to gradually adjust <abbr>POSIX</abbr> clocks near a leap second so that they disagree with <abbr>UTC</abbr> by at most a half second, even though every <abbr>POSIX</abbr> minute has exactly -sixty seconds. This approach works with the default <code>tz</code> +sixty seconds. This approach works with the default <code><abbr>tz</abbr></code> "<code>posix</code>" configuration, is <a href="http://bk1.ntp.org/ntp-stable/README.leapsmear">supported</a> by the <abbr>NTP</abbr> reference implementation, and is used by major -- 2.17.1

1 0

São Tomé and Príncipe tz change (Jan 1, 2019)
by Vadim Nasardinov Dec. 30, 2018

Dec. 30, 2018

São Tomé and Príncipe is about to do the following on Jan 1, 2019: http://www.stp-press.st/2018/12/05/governo-jesus-ja-decidiu-repor-hora-lega… “O Conselho de Ministros, relativamente a hora legal de São Tomé e Príncipe, decidiu que a partir de 1 de Janeiro de 2019 será reposta a nossa hora secular” I don't read Portuguese but this sounds like a change. Old news? I don't see any discussion of this in https://mm.icann.org/pipermail/tz/2018-December/thread.html

4 4

[tz-announce] 2018h release of tz code and data available
by Paul Eggert Dec. 29, 2018

Dec. 29, 2018

The 2018h release of the tz code and data is available. It reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Briefly: Qyzylorda, Kazakhstan moved from +06 to +05 on 2018-12-21. New zone Asia/Qostanay because Qostanay, Kazakhstan didn't move. Metlakatla, Alaska observes PST this winter only. Guess Morocco will continue to adjust clocks around Ramadan. Add predictions for Iran from 2038 through 2090. Changes to future timestamps Guess that Morocco will continue to fall back just before and spring forward just after Ramadan, the practice since 2012. (Thanks to Maamar Abdelkader.) This means Morocco will observe negative DST during Ramadan in main and vanguard formats, and in rearguard format it stays in the +00 timezone and observes ordinary DST in all months other than Ramadan. As before, extend this guesswork to the year 2037. As a consequence, Morocco is scheduled to observe three DST transitions in some Gregorian years (e.g., 2033) due to the mismatch between the Gregorian and Islamic calendars. The table of exact transitions for Iranian DST has been extended. It formerly cut off before the year 2038 in a nod to 32-bit time_t. It now cuts off before 2091 as there is doubt about how the Persian calendar will treat 2091. This change predicts DST transitions in 2038-9, 2042-3, and 2046-7 to occur one day later than previously predicted. As before, post-cutoff transitions are approximated. Changes to past and future timestamps Qyzylorda (aka Kyzylorda) oblast in Kazakhstan moved from +06 to +05 on 2018-12-21. This is a zone split as Qostanay (aka Kostanay) did not switch, so create a zone Asia/Qostanay. Metlakatla moved from Alaska to Pacific standard time on 2018-11-04. It did not change clocks that day and remains on -08 this winter. (Thanks to Ryan Stanley.) It will revert to the usual Alaska rules next spring, so this change affects only timestamps from 2018-11-04 through 2019-03-10. Change to past timestamps Kwajalein's 1993-08-20 transition from -12 to +12 was at 24:00, not 00:00. I transcribed the time incorrectly from Shanks. (Thanks to Phake Nick.) Nauru's 1979 transition was on 02-10 at 02:00, not 05-01 at 00:00. (Thanks to Phake Nick.) Guam observed DST irregularly from 1959 through 1977. (Thanks to Phake Nick.) Hong Kong observed DST in 1941 starting 06-15 (not 04-01), then on 10-01 changed standard time to +08:30 (not +08). Its transition back to +08 after WWII was on 1945-09-15, not the previous day. Its 1904-10-30 change took effect at 01:00 +08 (not 00:00 LMT). (Thanks to Phake Nick, Steve Allen, and Joseph Myers.) Also, its 1952 fallback was on 11-02 (not 10-25). This release contains many changes to timestamps before 1946 due to Japanese possession or occupation of Pacific/Chuuk, Pacific/Guam, Pacific/Kosrae, Pacific/Kwajalein, Pacific/Majuro, Pacific/Nauru, Pacific/Palau, and Pacific/Pohnpei. (Thanks to Phake Nick.) Assume that the Spanish East Indies was like the Philippines and observed American time until the end of 1844. This affects Pacific/Chuuk, Pacific/Kosrae, Pacific/Palau, and Pacific/Pohnpei. Changes to past tm_isdst flags For the recent Morocco change, the tm_isdst flag should be 1 from 2018-10-27 00:00 to 2018-10-28 03:00. (Thanks to Michael Deckers.) Give a URL to the official decree. (Thanks to Matt Johnson.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2018h.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2018h.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2018h.tar.lz As usual, links to the latest release files are here: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 7db91b70ae4ce85c7520960840fc957541a3bdb0 dated 2018-12-23 17:59:32 -0800 and tagged '2018h' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: e30ee77432a07a4f206f7a494bd3b4ed16805017d9907fa42bfc8b952332a3c63e2c344b99ef6b32cae70b0ba25c2068b69f65afec3378f9ce56194d85df1ef8 tzcode2018h.tar.gz 2c72fc2737b896f60c96cd2df80ede19c0fa80c4cd2fac350d13c673e851aac54c6cc7c8a865edb3f325fc0139b850b4b98a29d97967b643bbfaa7e8fa9b4937 tzdata2018h.tar.gz 5c64b894033d81a82d11177b991dbe93b5ab596453cf7c0f29dcab527c5d061dd56e03460091f938d9685d200c4c79bf082dc557eaf7b8ab370dfad9e43fe4e1 tzdb-2018h.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwgPpIACgkQ7ZfpDmKq fjTNyRAAlGlcaHLrGaiGgr8sKAI3Hd53zu53BUhTJjS8FO9WF2OxgDKkj0Yqrzuo CHz3eUuIIYJ2X7BLuCAKY842K2je5goS20jqEirlbEhg1Pd0uU/8FtC4L80l68y8 8LxKEMcYY7Ec9tTraZYNIKmFxL3s9v1vXwiF94FbiPftNALNUnYS2SvvBaVybo66 Tr1DUHz00qRDzZpi9+90FllpOcMOU4PHsds/QpsGd3Q5d7lnQpUCFNN3pxORN4/T LxCJVyBjxJ5zl+G1FVxVjJL1Hrh3VpQkV3MyplmDG9eBwOXBbwLITqvL66i1slpX o9rN0cSNlte1yoxZwcvWKV+2mDGeGJ2P4Hbzq11ZNZ+ZhKZMdu6mMd48hhcCCQqy 5BkIPLEI++8IGZUyoIWEa/wW2djmym1p5a1jUxmI2L/LfwztVnZz+qtPB0khFP8a lqIDXRSXv/ScGpL7TWaL7Rmc5V755/0lGy6s44pCYWS9SBhW29VRFsEkMRl8yAKM R/cRkWbiCvDvgDiZwdtQvCdKPB+HBebIMnyJb7IDKKYpqYRkdfpuXp2lq8xRtfoZ OhZKPYG8D9LC9ovFiRhsdYUde6Oou1DYUPayXZ8/zVXTVnswMaVh4cIoxU9pecUY hYqyE3iwCc0YpWTU47DzruY/sXSmaITxFPF0c24DbQkAhpkRKUk= =NHCF -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwgPpIACgkQ7ZfpDmKq fjT95BAAifCqZHNjQ+Rm8nG3PXu9+FYuqn8+ezIH5vjhcfdQepYDsC5q91+Echx3 2OQpkOB4sjBiHSeeYzu4j6ULm8bvMj+FNGVQz+LXR6AUfnMwGhLM5pyGtHo3VJDh uSUfyzLb505FxT54NyINlr2gPuV5CSP98IQQRAqzjUIxRRC78GDXA+brOjObB/d3 A0apTx0IKu/KiepbSQ2wetM9d92Brb366iPnp1aZQKuiuC4k2nGSC5zo3Jr4HLzA CYL6YVTQuqc1UMyhqBy5yJJExsmheo3Uuz2Vh6bi6FYFNxNiOMLfIfgVZyeNBAk/ 0I9Y3wWh65d4+GJwyOEdNACKqWBfWfHgOwGtheCXBMM1DDypIh7+GQsKo9zOs0n6 Kn7byx4/YMLpqPpd3J7PF5cWJtocVJUivi9RTe7n2zRAoqCT1+vM6YcXsdwbPn1g yI/iBvjvzo10k5fU2dtkRjyKO97kn+KXALVYEnsaUsAHtO3KlppSDYtsxZo37k3B y7ZWmfrFkSLI5U5xKszziLYF362FnEeRKVzNOPOGjs2kJpiu/alGpdxHJKDAtpms paszof0NglEzO+jx9OOcxNHZOGjWRKRxv5BSZw1io8q87xV+eyiGR38zFCLnG/9L udZRijZ5tp7JlxJ6XrqUKPrwDwnlPGCO5G+W2sVsQyEQYKiZZOo= =J8dK -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwgPpQACgkQ7ZfpDmKq fjRaOhAAphyNU0lclXv7YaLXm9SusHp8ElpMN/Okh2BK5dwSfHtECVow5hzKccXA 8TC9srW5DDAUEa08Qv20FNODYTk5ukpphk2IDiUMrjzy+99gkzPd5e9sBC8PHsUU HoiFMIHvsge0WhZMpNalrrdO8tjkRRL4sPui+pvO87cNGNOGJruNUA7BHh/tjugr EP2sDBsB+0tfpDAVzKnf3bvS/ZT/vS4imHRZ+TH5szRgSHWrZYt1IH26b4TmRr1y xfeUS2UsfgiEtTt8/CKwChGHh/ZB+Rp+P7iWQjG15fLrtd7+Of7thRi2BxKsCT1a EXRaBfRkn1HSeYL+a5qSGNrZX4ZKzfWuRlJWCZhoogyZ1tyd2XVnJ5XneKwMaAKH bqdo+wscYB7YwGZXL3LX7tXJzggkXjxljggUHs0eotsLjfxaHVr/tcK8nuz8DNVK gTEmczpQ8ygsycVvkH2Cseh7ETMLjazTD+NTh69jLWCG1At9kGNwoekeJb+Rf7we ErDGPOE0+rp3AXQAxnu8FaWBBwCfqsvH8cls5/v3jBwtN75GM0b8Ui+HfleejTS1 SyoQsQMqVdvtXuZG/qM+FQyIXAkZ+WR+36FotL55GPT58hZhBJL+WlgyL6B30HUI VNBAfdkOdgwN30D20guM68JRGs5dqMr+gg+sajOPgMnl2xk7F30= =Lqgu -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets, this particular release's data entries are also available in a rearguard-format tarball and signature that does not contain such offsets. This is intended to be a temporary transition aid for these parsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2018h/tzdata2018h-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2018h/tzdata2018h-rearguard.tar.… with the following SHA-512 and GPG checksums: 73ed819507ed966ea962a6adb5fbaeff4f416036573757b893d29f7c62f5c9b04c5cebea7e52cd0f502cd49195499719ca76f57e9883bb4de6dadeb87b51ca71 tzdata2018h-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwgPpMACgkQ7ZfpDmKq fjRcUw//UnGM+2HY12mtu6AJ2aYb1PjzUv0X6FADua7YDOyXjz5i0sXXi7D2EPa0 qeZuk4x0Zr2EN8vt3Xy9jHuhpLr8bAJn8cwb71sNm+tSdDvKLoJJcokj7QKjBWr9 MTprLgI0guOhOdinSFFnHaumPtXzhOjrYJiy40Qw4RMZH1sTZhPWrSK3kZlpJj+t zGYbskaJtXB1LhlQbUtgepxyV5AaJfz4owYIbYh+Uv0gGqDzJc94BCVxM89LN52l CCHzt3zrsMicBle4QhyRo1qk6D4DDGVq2+AXLMyq8oMQvNvtzFpw34CbsYLaNL9X 3kdCqV723lbTwpqKEcivRhCCc3m2i/0rt1X1nkReXdzior3AJpAtG48pcb/F3/l4 Hc2Af8uohIhYBpw0Tm+x6YL2u1+ZR52rJtzt5UVcWV3ToyJJw1tTCijxxEHd/xoh 6xhtvYVPKkKabQqHUQnp0YKqV6DF83pMeQ4MLtSp7LPrNbxL9y5WvjAMhjzeQAB9 8qtDUQ9tPlSgMvs7EO7LCfUuPji5pPXoWn4caYn3KkFQPYSS0FYTv+RvBlZVjaAJ 84KTx87fD6ren0/XEyIYhtN30TxNng/KODFcmM4KM2+Jk5eVKktrY7N3uZZBEpQ8 H9i/8giTDGPE/hlI3LN1E15FPuC6o0PGYaDUT8Mkk4CjazJEPA8= =9v4P -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Time zone offset changed in Qyzylorda, Kazakhstan
by Askar Timirgazin Dec. 29, 2018

Dec. 29, 2018

Hello there, please consider that according to https://legalacts.egov.kz/npa/view?id=2000931 time offset for zone Asia/Qyzylorda from 21 Dec 2018 must be set to UTC+5 instead of UTC+6 -- Best regards, Askar Timirgazin

2 1