- tz - lists.iana.org

KyivNotKiev
by Andriy Ivanchenko Nov. 27, 2020

Nov. 27, 2020

Hello What do I need to do for you to make such changes? https://en.wikipedia.org/wiki/KyivNotKiev Are such changes possible? Original: Вітаю Що я повинен зробити, щоб ви зробили подібні зміни? https://uk.wikipedia.org/wiki/KyivNotKiev Такі зміни можливі?

22 49

Some time zone history (1)
by P Chan Nov. 25, 2020

Nov. 25, 2020

Australia Legislation related to the DST in 1917 and 1942-1944: Daylight Saving Act 1916 (No. 40 of 1916) [1916-12-21, commenced on 1917-01-01] http://classic.austlii.edu.au/au/legis/cth/num_act/dsa1916401916192/ Daylight Saving Repeal Act 1917 (No. 35 of 1917) [1917-09-25] http://classic.austlii.edu.au/au/legis/cth/num_act/dsra1917351917243/ Statutory Rules 1941, No. 323 [1941-12-24] https://www.legislation.gov.au/Details/C1941L00323 Statutory Rules 1942, No. 392 [1942-09-10] https://www.legislation.gov.au/Details/C1942L00392 Statutory Rules 1943, No. 241 [1943-09-29] https://www.legislation.gov.au/Details/C1943L00241 All transition times should be 02:00 standard time. Tasmania observed DST in 1916-1919. Daylight Saving Act, 1916 (7 Geo V, No 2) [1916-09-22] http://classic.austlii.edu.au/au/legis/tas/num_act/tdsa19167gvn2267/ Daylight Saving Amendment Act, 1917 (8 Geo V, No 5) [1917-10-01] http://classic.austlii.edu.au/au/legis/tas/num_act/tdsaa19178gvn5347/ Daylight Saving Act Repeal Act, 1919 (10 Geo V, No 9) [1919-10-24] http://classic.austlii.edu.au/au/legis/tas/num_act/tdsara191910gvn9339/ King Island is only mentioned in the 1967 Act but not the 1968 Act. Therefore it possibly observed DST from 1968/69. Daylight Saving Act 1967 (No. 33 of 1967) [1967-09-22] http://classic.austlii.edu.au/au/legis/tas/num_act/dsa196733o1967211/ Daylight Saving Act 1968 (No. 42 of 1968) [1968-10-15] http://classic.austlii.edu.au/au/legis/tas/num_act/dsa196842o1968211/ ---------- Bermuda Apart from the current rules, DST was also observed in 1917-1918, 1942-1945, 1947-1952 and 1956. Most of the information can be found online from the Bermuda National Library - Digital Collection which includes The Royal Gazette (RG) until 1957 https://bnl.contentdm.oclc.org/digital/ I will cite the ID. For example, [10000] means https://bnl.contentdm.oclc.org/digital/collection/BermudaNP02/id/10000 1917: Apr 5 midnight to Sep 30 midnight Daylight Saving Act, 1917 (1917 No. 13) [1917-04-02] Bermuda Acts and Resolves 1917, p 37-38 https://books.google.com/books?id=M-lCAQAAMAAJ&pg=PA36-IA2 RG, 1917-04-04, p 6 [42340] gives the spring forward date. 1918: Apr 13 midnight to Sep 15 midnight Daylight Saving Act, 1918 (1918 No. 9) [1918-04-06] Bermuda Acts and Resolves 1917, p 13 https://books.google.com/books?id=K-lCAQAAMAAJ&pg=RA1-PA7 Note that local mean time was still used before 1930. During WWII, DST was introduced by Defence Regulations 1942: Jan 11 02:00 to Oct 18 02:00 [113646], [115726] 1943: Mar 21 02:00 to Oct 31 02:00 [116704], [118193] 1944: Mar 12 02:00 to Nov 5 02:00 [119225], [121593] 1945: Mar 11 02:00 to Nov 4 02:00 [122369], [124461] RG, 1942-01-08, p 2, 1942-10-12, p 2 , 1943-03-06, p 2, 1943-09-03, p 1, 1944-02-29, p 6, 1944-09-20, p 2, 1945-02-13, p 2, 1945-11-03, p 1 In 1946, the House of Assembly rejected DST twice. [128686], [128076] RG, 1946-03-16 p 1,1946-04-13 p 1 1947: third Sunday in May 02:00 to second Sunday in September 02:00 DST in 1947 was defined in the Daylight Saving Act, 1947 (1947: No. 12) which expired at the end of the year. [125784] ,[132405], [144454], [138226] RG, 1947-02-27, p 1, 1947-05-15, p 1, 1947-09-13, p 1, 1947-12-30, p 1 1948-1952: fourth Sunday in May 02:00 to first Sunday in September 02:00 DST in 1948 was defined in the Daylight Saving Act, 1948 (1948 : No. 12) which was set to expired at the end of the year but it was extended until the end of 1952 and was not further extended. [129802], [139403], [146008], [135240], [144330], [139049], [143309], [148271], [149773], [153589], [153802], [155924] RG, 1948-04-13, p 1, 1948-05-22, p 1, 1948-09-04, p 1, 1949-05-21, p1, 1949-09-03, p 1, 1950-05-27 p 1, 1950-09-02, p 1, 1951-05-27, p 1, 1951-09-01, p 1, 1952-05-23, p 1, 1952-09-26, p 1, 1952-12-21, p 8 In 1953-1955, the House of Assembly rejected DST each year. [158996], [162620], [166720] RG, 1953-05-02, p 1, 1954-04-01 p 1, 1955-03-12, p 1 1956: fourth Sunday in May 02:00 to last Sunday in October 02:00 Time Zone (Seasonal Variation) Act, 1956 (1956: No.44) [1956-05-25] Bermuda Public Acts 1956, p 331-332 https://books.google.com/books?id=Xs1AlmD_cEwC&pg=PA63 The extension of the Act was rejected by the House of Assembly. [176218] RG, 1956-12-13, p 1 >From the Chronological Table of Public and Private Acts up to 1985, it seems that there does not exist other Acts related to DST before 1973. https://books.google.com/books?id=r9hMAQAAIAAJ&pg=RA23-PA1 Public Acts of the Legislature of the Islands of Bermuda, Together with Statutory Instruments in Force Thereunder, Vol VII ---------- Gold Coast (Ghana) Interpretation Amendment Ordinance, 1915 (No.24 of 1915) [1915-11-02] Ordinances of the Gold Coast, Ashanti, Northern Territories 1915, p 69-71 https://books.google.com/books?id=ErA-AQAAIAAJ&pg=PA70 This Ordinance added "'Time' shall mean Greenwich Mean Time" to the Interpretation Ordinance, 1876. Determination of the Time Ordinance, 1919 (No. 18 of 1919) [1919-11-24] Ordinances of the Gold Coast, Ashanti, Northern Territories 1919, p 75-76 https://books.google.com/books?id=MbA-AQAAIAAJ&pg=PA75 This Ordinance removed the previous definition of time and introduced DST. Time Determination Ordinance (Cap. 214) The Laws of the Gold Coast (including Togoland Under British Mandate) Vol. II (1937), p 2328 https://books.google.com/books?id=Z7M-AQAAIAAJ&pg=PA2328 Revised edition of the 1919 Ordinance. Time Determination (Amendment) Ordinance, 1940 (No. 9 of 1940) [1940-04-06] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1940, p 22 https://books.google.com/books?id=1ao-AQAAIAAJ&pg=PA22 This Ordinance changed the forward transition from September to May. Defence (Time Determination Ordinance Amendment) Regulations, 1942 (Regulations No. 6 of 1942) [1942-01-31, commenced on 1942-02-08] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1942, p 48 https://books.google.com/books?id=Das-AQAAIAAJ&pg=PA48 These regulations advanced the time by thirty minutes. Defence (Time Determination Ordinance Amendment (No.2)) Regulations, 1942 (Regulations No. 28 of 1942) [1942-04-25] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1942, p 87 https://books.google.com/books?id=Das-AQAAIAAJ&pg=PA87 These regulations abolished DST and changed the time to GMT+0:30. Defence (Revocation) (No.4) Regulations, 1945 (Regulations No. 45 of 1945) [1945-10-24, commenced on 1946-01-06] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1945, p 256 https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA256 These regulations revoked the previous two sets of Regulations. Time Determination (Amendment) Ordinance, 1945 (No. 18 of 1945) [1946-01-06] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1945, p 69 https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA69 This Ordinance abolished DST. Time Determination (Amendment) Ordinance, 1950 (No. 26 of 1950) [1950-07-22] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1950, p 35 https://books.google.com/books?id=e60-AQAAIAAJ&pg=PA35 This Ordinance restored DST but with thirty minutes offset. Time Determination Ordinance (Cap. 264) The Laws of the Gold Coast, Vol. V (1954), p 380 https://books.google.com/books?id=Mqc-AQAAIAAJ&pg=PA380 Revised edition of the Time Determination Ordinance. Time Determination (Amendment) Ordinance, 1956 (No. 21 of 1956) [1956-08-29] Annual Volume of the Ordinances of the Gold Coast Enacted During the Year 1956, p 83 https://books.google.com/books?id=VLE-AQAAIAAJ&pg=PA83 This Ordinance abolished DST.

2 4

Fwd: [IANA #1173666] Time zone change - Yukon Canada
by Paul Eggert Nov. 25, 2020

Nov. 25, 2020

Thanks, I'm forwarding this to the tz mailing list so that the OIC is archived. -------- Forwarded Message -------- Subject: Re: [tz] [IANA #1173666] Time zone change - Yukon Canada Date: Tue, 24 Nov 2020 14:00:25 -0700 From: Brian Inglis <Brian.Inglis(a)SystematicSw.ab.ca> Reply-To: Brian.Inglis(a)SystematicSw.ab.ca Organization: Systematic Software To: Andrew.Smith(a)gov.yk.ca CC: Paul Eggert <eggert(a)cs.ucla.edu>, Tim Parenti <tim(a)timtimeonline.com> Hi Andrew, Thanks very much for following up on those and getting back to me: I have an interest in these Canadian laws and orders and been digging on Yukon and other sites a number of times. I realize that unfortunately many of these laws and orders are short documents that could easily be missed stuck to others in files, or during scanning, and lost to posterity, or may turn up unexpectedly elsewhere at some later date. I will add this OIC to my personal archive of Canadian and Yukon tz history and pass it along to the tz maintainers who may publish it on the public repositories. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada [PMed to maintainers as received off-list - hope you guys don't mind? Please credit Andrew for any publication.] On 2020-11-24 10:57, Andrew.Smith(a)gov.yk.ca wrote: > Hi Brian - > Following up on this now that the dust has settles in Yukon. > I have attached OIC 1980-02. > My legislative colleagues have let me know that they do not have a copy of CO 1966-20 available in their records (it may be archived deep in the stacks or lost in the intervening half-century). > > Be well. > > Andrew G. Smith > Intergovernmental Relations > Executive Council Office > Government of Yukon > T: 867-667-5875 > > Perhaps the Yukon Government representative could also help us fill a couple of holes in Yukon legislative time zone history and comments in: > > http://mm.icann.org/pipermail/tz/2015-April/022200.html > and > > http://mm.icann.org/pipermail/tz/attachments/20150417/4ba8d35e/0001-Better-… > > ✱ CO 1966-20 establishing Yukon (East) Standard Time (like PST) and Yukon (West) Standard Time (like YST) is not available on the Yukon, CanLii, or other sites, although it was revoked by CO 1967-59; from: > > Standard Time and Time Zones in Canada; Thomson, Malcolm M.; JRASC, Vol. 64, pp.129-162; June 1970; SAO/NASA Astrophysics Data System (ADS) http://adsabs.harvard.edu/abs/1970JRASC..64..129T p.156: > > "Yukon Territory Commissioner's Order 1967-59 Interpretation Ordinance > > The Commissioner of the Yukon Territory, pursuant to the Interpretation Ordinance, is pleased to and doth hereby order as follows: > > 1. Commissioner's Order 1966-20 dated at Whitehorse in the Yukon Territory on 27th January, 1966, is hereby revoked." > > ✱ OIC 1980/02 establishing Yukon DST is not available on the Yukon, CanLii, or other sites, although it was revoked by OIC 1987/56; from: > > Yukon Daylight Saving Time, YOIC 1987/56 http://www.canlii.org/en/yk/laws/regu/yoic-1987-56/latest/yoic-1987-56.html > > "O.I.C. 1987/056 INTERPRETATION ACT > > INTERPRETATION ACT > Pursuant to section 36 of the Interpretation Act, the Commissioner in Executive Council orders as follows: > > 1. In every year between > (a) two o'clock in the morning in the first Sunday in April, and > (b) two o'clock in the morning in the last Sunday in October, Standard Time shall be reckoned as seven hours behind Greenwich Time and called Yukon Daylight Saving Time. > > 2. Order-In-Council 1980/02 is hereby revoked."

1 1

What's "right"?
by Paul Gilmartin Nov. 17, 2020

Nov. 17, 2020

Hello, TZ, In: ftp://ftp.iana.org/tz/tz-link.html I read: The tz code and data support leap seconds via an optional "right" configuration, ... Empirically, this seems to assume time_t of TAI-10. This isn't GPS, which I understand to be TAI-19: http://www.bipm.org/utils/en/pdf/time_ann_rep/Time_annual_report_2015/25_ut… TAI-10 is (accidentally?) the epoch of the IBM z/OS TOD clock. I find a couple references to "zoneinfo/right" in Makefile and NEWS. Is there more complete documentation of "right" and its rationale elsewhere? Thanks, gil

12 56

TIme in Belize
by P Chan Nov. 12, 2020

Nov. 12, 2020

Below are some laws related to the time in British Honduras/Belize: Definition of Time Ordinance, 1927 (No.4 of 1927) [1927-04-01] Ordinances of British Honduras Passed in the Year 1927, p 19-20 https://books.google.com/books?id=LqEpAQAAMAAJ&pg=RA3-PA19 Definition of Time (Amendment) Ordinance, 1942 (No. 5 of 1942) [1942-06-27] Ordinances of British Honduras Passed in the Year 1942, p 31-32 https://books.google.com/books?id=h6MpAQAAMAAJ&pg=RA6-PA95-IA44 Definition of Time Ordinance, 1945 (No. 19 of 1945) [1945-12-15] Ordinances of British Honduras Passed in the Year 1945, p 49-50 https://books.google.com/books?id=xaMpAQAAMAAJ&pg=RA2-PP1 Definition of Time Ordinance, 1947 (No. 1 of 1947) [1947-03-11] Ordinances of British Honduras Passed in the Year 1947, p 1-2 https://books.google.com/books?id=xaMpAQAAMAAJ&pg=RA3-PA1 Time (Definition of) Ordinance (Chapter 180) The Laws of British Honduras in Force on the 15th Day of September, 1958 , Volume IV, p 2580 https://books.google.com/books?id=v5QpAQAAMAAJ&pg=PA2580 Time (Definition of) (Amendment) Ordinance, 1968 (No. 13 of 1968) [1968-08-03] https://books.google.com/books?id=xij7KEB_58wC&pg=RA1-PA428-IA9 Definition of Time Act (Chapter 339) Law of Belize, Revised Edition 2000 http://www.belizelaw.org/web/lawadmin/PDF%20files/cap339.pdf

5 14

Yukon time - Google contact?
by Andrew.Smith＠gov.yk.ca Nov. 2, 2020

Nov. 2, 2020

Hi all. Is there anyone from Google on the list, or has a Google contact for time? I tried getting in touch with their Canada offices earlier, but they didn't get back to me. Yukon is on our new time now, but some Google services are showing us incorrectly on Pacific Standard Time. Google Home and Chrome specifically are showing that, Android is displaying correctly. Thanks. Hope this is the biggest hiccup we see up here. [cid:image001.png@01D6B07D.A5900CD0] Andrew G. Smith Intergovernmental Relations Executive Council Office T 867-667-5875 | C 867-335-6008 | Yukon.ca

1 1

[PROPOSED] Port 'make rearguard_tarballs' to Solaris 10
by Paul Eggert Oct. 27, 2020

Oct. 27, 2020

* Makefile (tarballs, etc.): Export AWK to submake, for Solaris 10 which needs something like 'make AWK=nawk rearguard_tarballs'. (.KEEP_STATE): Remove. .KEEP_STATE is a Solaris 'make' feature that breaks 'make rearguard_tarballs' because it causes submakes to mistakenly consider files to be out-of-date. As .KEEP_STATE is not specified by POSIX and is ignored by GNU 'make' it should not be needed. --- Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Makefile b/Makefile index a0b6aeb..5064a19 100644 --- a/Makefile +++ b/Makefile @@ -1012,7 +1012,7 @@ tarballs rearguard_tarballs traditional_tarballs \ signatures rearguard_signatures traditional_signatures: \ version set-timestamps.out rearguard.zi VERSION=`cat version` && \ - $(MAKE) VERSION="$$VERSION" $@_version + $(MAKE) AWK='$(AWK)' VERSION="$$VERSION" $@_version # These *_version rules are intended for use if VERSION is set by some # other means. Ordinarily these rules are used only by the above @@ -1110,8 +1110,6 @@ strftime.o: private.h tzfile.h zdump.o: version.h zic.o: private.h tzfile.h version.h -.KEEP_STATE: - .PHONY: ALL INSTALL all .PHONY: check check_time_t_alternatives .PHONY: check_web check_zishrink -- 2.25.1

1 0

Israel DST
by P Chan Oct. 27, 2020

Oct. 27, 2020

Here is a full list of the orders related to the DST in Mandatory Palestine/Israel in 1940-2004.

4 5

Yukon and the zone.tab file
by Chris Walton Oct. 26, 2020

Oct. 26, 2020

The two Yukon entries in the zone.tab file still have descriptions with the name "Pacific": CA +6043-13503 America/Whitehorse *Pacific* - Yukon (east) CA +6404-13925 America/Dawson *Pacific* - Yukon (west) Please consider changing the descriptions to something like this: CA +6043-13503 America/Whitehorse *MST* - Yukon (east) CA +6404-13925 America/Dawson *MST* - Yukon (west) Thank you. -chris

2 1

State of Palestine Time zone - need to update
by heba.hamad＠mtit.gov.ps Oct. 26, 2020

Oct. 26, 2020

,Dear Sir.I’m Heba Hamad .I have been appointed as a focal point by the Ministry of telecommunication and information technology (state of Palestine) to communicate with you I’m contacting you in regard to the time zone data base the field related to the state of Palestine. I checked the published data regarding the time zones related to Palestine and noticed that it’s not accurate, and hence I would like to ask for an update to the time zone data base related to Palestine to be as follow PS State of Palestine Asia/AlQuds UTC +2:00 :Instead of the following data PS State of Palestine Asia/Gaza UTC +2:00 PS State of Palestine Asia/Hebron UTC +2:00 .Kindly advise if any documents, information or procedures are needed from our side ,Best Regards

3 2

My public key via GitHub and WKD for verifying tzdb distributions
by Paul Eggert Oct. 25, 2020

Oct. 25, 2020

Recently users have had trouble verifying tzdb releases because they could not obtain the GPG public key that I use to sign the releases. These problems stem from the denial-of-service attacks on public keyservers last year, combined with my extending the expiration of my longstanding public key, which had been due to expire in August. The expiration-date extension had problems propagating to public keyservers that use the traditional method of key distribution. To try to help ameliorate this problem I recently did two things. First, I uploaded my public key to the development repository on GitHub. You can now use <https://github.com/eggert/tz/tags> to verify every tzdb release starting with 2012e. (Older releases are not tagged, as discussed in the 2013f NEWS entry.) Second, at my suggestion the UCLA Computer Science Department has added WKD support to cs.ucla.edu, and you can now verify my key independently via WKD. See an example below for how to do this. In the longer term, the IANA have been working on a way to have IANA authorities sign distributions, and eventually we hope to have something implemented along those lines. Thanks to Phil Pennock for his suggestions and help in improving the process of verifying tzdb distributions. PS. For more about last year's denial-of-service attacks and the use of WKD instead of traditional public keyservers, please see: Osborne C. PGP SKS key network poisoned by unknown hackers. ZDNet. 2019-07-04. https://www.zdnet.com/article/openpgp-flooded-with-spam-by-unknown-hackers/ Koch W. OpenPGP Web Key Directory. Active Internet-Draft. 2020-05-26. https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ What is a Web Key Directory? GnuPG e.V. 2020-07-06. https://wiki.gnupg.org/WKD PPS. Here is one way to verify a key via WKD, using the 'gpg' shell command. You'll need a recent-enough GnuPG: version 2.1.23 (2017-08-23) or later should suffice. $ gpg --auto-key-locate wkd --locate-keys eggert(a)cs.ucla.edu gpg: key ED97E90E62AA7E34: public key "Paul Eggert <eggert(a)cs.ucla.edu>" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: no ultimately trusted keys found pub rsa4096 2010-09-03 [SC] [expires: 2021-08-31] 7E3792A9D8ACF7D633BC1588ED97E90E62AA7E34 uid [ unknown] Paul Eggert <eggert(a)cs.ucla.edu> sub rsa4096 2010-09-03 [E] [expires: 2021-08-31]

1 0

Re: [tz] tz leap-seconds.list
by Paul Eggert Oct. 25, 2020

Oct. 25, 2020

On 10/25/20 10:45 AM, Kristin Minchev wrote: > The [leap-seconds.list] file itself doesn't have any license information > (nor NIST's). Under current US law a file that contains no license information normally defaults to being copyrighted with no license granted. The NIST is an arm of the US government, though, so under US law its publications are public domain so we don't have to worry about redistributing the NIST file even though it contains no license info. I just now searched for the top ten "leap-seconds.list" hits on Google. The #1, #3, #4, #6, #7 and #9 hits were about the NIST file, and of these all but #9 were about the tzdb copy of the NIST file (#9 was unclear). The #5 and #10 hits were about the IERS file. (#2 and #8 were false matches.) So even though the IERS file is published by the primary source for leap seconds, licensing issues have prevented the IERS file from being the most popular in practice. We've attempted to contact the IERS multiple times to get its file's license clarified, but haven't made much progress. > And most of the data comes from IERS anyway. That's fine: under US law, data cannot be copyrighted. There was a court case about this; see <https://www.eff.org/press/releases/eff-wins-protection-time-zone-database>. I installed the attached patch to the tzdb development repository to try to explain this all a bit better, without getting too long-winded about it.

1 0

Time in Kenya
by P Chan Oct. 24, 2020

Oct. 24, 2020

The standard time of GMT+2:30 was adopted in the East Africa Protectorate on 1 May 1908. https://books.google.com/books?id=e-cAC-sjPSEC&pg=PA274 At midnight on 30 June 1928 the clocks throughout Kenya was put forward half an hour by the Alteration of Time Ordinance, 1928. https://gazettes.africa/archive/ke/1928/ke-government-gazette-dated-1928-05… https://books.google.com/books?id=2S0S6os32ZUC&pg=PA813 The 1928 ordinance was repeal by the Alteration of Time (repeal) Ordinance, 1929 and the time was restored to GMT+2:30 at midnight on 4 January 1930. https://books.google.com/books?id=_g18jIZQlwwC&pg=PA2701 The Alteration of Time Ordinance, 1936 changed the time to GMT+2:45 and repealed the previous ordinance at midnight on 31 December 1936 . https://books.google.com/books?id=K7j41z0aC5wC&pg=PA705 The Defence (Amendment of Laws No. 120) Regulations changed the time to GMT+3 at midnight on 31 July 1942. https://books.google.com/books?hl=zh-TW&id=c_E-AQAAIAAJ&pg=PA331 The provision of the 1936 ordinance was not repealed and was later incorporated in the Interpretation and General Clauses Ordinance in 1948. Although it was overridden by the 1942 regulations. https://dds.crl.edu/item/217517 (p.101) In 1950, the Interpretation and General Clauses Ordinance was amended to adopt GMT+3 permanently as the 1942 regulations were due to expire on 10 December. https://books.google.com/books?id=jvR8mUDAwR0C&pg=PA787 https://books.google.com/books?id=-_dQAQAAMAAJ&pg=PA294

3 2

make rearguard_tarballs fails creates tzdataunknown-rearguard.tar.gz file with latest tzdata lzip
by Carlos Jimenez Oct. 22, 2020

Oct. 22, 2020

Hello, I've encountered two issues with the two latest files for the tz changes: https://data.iana.org/time-zones/releases/tzdb-2020c.tar.lz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz 1) The touch command for the new pacificnew empty file won't work on centos6 or centos7. The date format syntax is generating an error: I noticed this was already fixed here: https://github.com/eggert/tz/commit/ce89cbaa436f336dca4b239fa528405abd7d84b… How long before that makes it to the /tzdb-2020c.tar.lz file? 2) Upon manually fixing the touch issue by replacing the touch command with the fixed version, I am now getting the wrong filenames for the rearguard file and tzcode and tzdata: Steps: [root@centos7 tzdb-2020c]# lzip -d tzdb-latest.tar.lz [root@centos7 tzdb-2020c]# mkdir tzdata-latest && tar xf tzdb-latest.tar -C tzdata-latest [root@centos7 tzdb-2020c]# pwd /home/tzdata/tzdata-2020c/tzdb-2020c [root@centos7 tzdb-2020c]# make rearguard_tarballs I get the following file as a result $tzdataunknown-rearguard.tar.gz I have reproduced this on centos6, centos7 and Mac OS 10.15.6. I get the following errors as well when I execute it: [root@centos6 tzdb-2020c]# make rearguard_tarballs >> ../../makeoutput.txt fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git Attached is the make output. This impacts us directly since we have customers in Fiji. I'm trying to reverse engineer and review what may be going wrong but any help would be great. -Carlos

2 2

Support for Etc/GMT -style zones ids with partial hours
by Neil Fuller Oct. 22, 2020

Oct. 22, 2020

Would there be any support in this community for adding new Etc/GMT[-+] zone identifiers but with partial hours? e.g. something like "Etc/GMT-5:30" These might introduce some technical challenges, but I can see a use which I will explain below. I haven't yet investigated the impact on Android (where I deal with much of the time zone work), but I thought I'd ask for thoughts before expending any effort prototyping. Thanks, Neil. ------------------ Motivating case: Taking Android as an example, the platform uses TZDB zone identifiers as the basis for most time zone support. Directly, via a tzif-based file (used for libc mktime/localtime / Android's custom implementation of java.util.TimeZone), and indirectly via ICU4C and ICU4J. In situations like we had this week with Palestine, i.e. less than one week's notice before a DST transition change, the usual advice for users affected is "Please manually select an alternative time zone that has the offset you need until you receive a software update". e.g. Microsoft Windows appears to do the same [1] Side note: There are related cases for devices that have fallen out of their OEM's support window and will never receive a TZDB update again. The utility of these devices can degrade over time as their version of TZDB slowly drifts from the user's reality. Users continuing to use these devices may no longer be able to use the identifier for their actual location and get the behavior they need. Instead, they have to select an alternative zone ID that has the offset they need. If they're not lucky, they may be forced to pick an alternative zone ID which has its own DST schedule which might not match their requirements for the full year. The Stock Android settings UI, starting with Android Pie (9.0), allows users to select from the fixed "Etc/GMT-5" style identifiers from TZDB in addition to the more regular "Europe/London"-style zone identifiers associated with geographical regions. The original use case for this was to allow pilots to select Etc/UTC, and we added support for selecting all the other fixed Etc/GMT[+-] zones at the same time. The current Etc/GMT[+-] zone identifiers in TZDB only cover whole hour offsets. There are various places that use 30 minute offsets, and a few that use 45/15 minute offsets [2]. For the cases where devices cannot receive rules updates (in time, or at all), it would be useful to have the full range of 30-minute fixed-offset possibilities for users to select from instead. I'm choosing to ignore the 15/45 minute ones right now as they appear much less common / useful. Because most of our infrastructure treats TZDB as "ground truth" it would be beneficial to get this support in TZDB rather than carrying local patches to each library. [1] https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/inter… - this example is for Fiji / 2020b [2] https://www.timeanddate.com/time/time-zones-interesting.html - zones with offsets other than integer hours -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902

3 6

[PATCH] Port to downstream HP-UX-style ‘make’
by Paul Eggert Oct. 22, 2020

Oct. 22, 2020

HP-UX ‘make’ considers a target to be out-of-date if its timestamp equals that of a dependency, and POSIX allows this ‘make’ behavior. So, when putting timestamps on files in tarballs, add 1 to a file’s timestamp if it depends on some other file with the same timestamp. That way, when someone unpackages a tarball on an HP-UX host, its ‘make’ will avoid rebuilding files like ‘version’ that are up-to-date in the tarball. * Makefile (SET_TIMESTAMP_N, SET_TIMESTAMP, SET_TIMESTAMP_DEP): New macros. (set-timestamps.out, set-tzs-timestamp.out) (tzdata$(VERSION)-rearguard.tar.gz, tzdb-$(VERSION).tar.lz): Use them instead of invoking ‘touch’ by hand. (set-timestamps.out): Set the timestamp of tzdata.zi after that of version, since the former depends on the latter. --- Makefile | 43 +++++++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index 40b81d1..3b9d59e 100644 --- a/Makefile +++ b/Makefile @@ -872,11 +872,34 @@ $(MANTXTS): workman.sh LC_ALL=C sh workman.sh `expr $@ : '$.*$\.txt$$'` >$@.out mv $@.out $@ +# Set file timestamps deterministically if possible, +# so that tarballs containing the timestamps are reproducible. +# +# '$(SET_TIMESTAMP_N) N DEST A B C ...' sets the timestamp of the +# file DEST to the maximum of the timestamps of the files A B C ..., +# plus N if GNU ls and touch are available. +SET_TIMESTAMP_N = sh -c '\ + n=$$0 dest=$$1; shift; \ + touch -cmr `ls -t "$$@" | sed 1q` "$$dest" && \ + if test $$n != 0 && \ + lsout=`ls -n --time-style="+%s" "$$dest" 2>/dev/null`; then \ + set x $$lsout && \ + touch -cmd @`expr $$7 + $$n` "$$dest"; \ + else :; fi' +# If DEST depends on A B C ... in this Makefile, callers should use +# $(SET_TIMESTAMP_DEP) DEST A B C ..., for the benefit of any +# downstream 'make' that considers equal timestamps to be out of date. +# POSIX allows this 'make' behavior, and HP-UX 'make' does it. +# If all that matters is that the timestamp be reproducible +# and plausible, use $(SET_TIMESTAMP). +SET_TIMESTAMP = $(SET_TIMESTAMP_N) 0 +SET_TIMESTAMP_DEP = $(SET_TIMESTAMP_N) 1 + # Set the timestamps to those of the git repository, if available, # and if the files have not changed since then. -# This uses GNU 'touch' syntax 'touch -d@N FILE', -# where N is the number of seconds since 1970. -# If git or GNU 'touch' is absent, don't bother to sync with git timestamps. +# This uses GNU 'ls --time-style=+%s', which outputs the seconds count, +# and GNU 'touch -d@N FILE', where N is the number of seconds since 1970. +# If git or GNU is absent, don't bother to sync with git timestamps. # Also, set the timestamp of each prebuilt file like 'leapseconds' # to be the maximum of the files it depends on. set-timestamps.out: $(EIGHT_YARDS) @@ -894,16 +917,16 @@ set-timestamps.out: $(EIGHT_YARDS) fi || exit; \ done; \ fi - touch -cmr `ls -t $(LEAP_DEPS) | sed 1q` leapseconds + $(SET_TIMESTAMP_DEP) leapseconds $(LEAP_DEPS) for file in `ls $(MANTXTS) | sed 's/\.txt$$//'`; do \ - touch -cmr `ls -t $$file workman.sh | sed 1q` $$file.txt || \ + $(SET_TIMESTAMP_DEP) $$file.txt $$file workman.sh || \ exit; \ done - touch -cmr `ls -t $(TZDATA_ZI_DEPS) | sed 1q` tzdata.zi - touch -cmr `ls -t $(VERSION_DEPS) | sed 1q` version + $(SET_TIMESTAMP_DEP) version $(VERSION_DEPS) + $(SET_TIMESTAMP_DEP) tzdata.zi $(TZDATA_ZI_DEPS) touch $@ set-tzs-timestamp.out: $(TZS) - touch -cmr `ls -t $(TZS_DEPS) | sed 1q` $(TZS) + $(SET_TIMESTAMP_DEP) $(TZS) $(TZS_DEPS) touch $@ # The zics below ensure that each data file can stand on its own. @@ -1018,7 +1041,7 @@ tzdata$(VERSION)-rearguard.tar.gz: rearguard.zi set-timestamps.out for f in $(TDATA) $(PACKRATDATA); do \ rearf=tzdata$(VERSION)-rearguard.dir/$$f; \ $(AWK) -v DATAFORM=rearguard -f ziguard.awk $$f >$$rearf && \ - touch -cmr `ls -t ziguard.awk $$f` $$rearf || exit; \ + $(SET_TIMESTAMP_DEP) $$rearf ziguard.awk $$f || exit; \ done sed '1s/$$/-rearguard/' \ <version >tzdata$(VERSION)-rearguard.dir/version @@ -1037,7 +1060,7 @@ tzdb-$(VERSION).tar.lz: set-timestamps.out set-tzs-timestamp.out rm -fr tzdb-$(VERSION) mkdir tzdb-$(VERSION) ln $(ENCHILADA) tzdb-$(VERSION) - touch -cmr `ls -t tzdb-$(VERSION)/* | sed 1q` tzdb-$(VERSION) + $(SET_TIMESTAMP) tzdb-$(VERSION) tzdb-$(VERSION)/* LC_ALL=C && export LC_ALL && \ tar $(TARFLAGS) -cf - tzdb-$(VERSION) | lzip -9 >$@.out mv $@.out $@ -- 2.25.1

1 0

Pacific/Norfolk Island DST
by Victor Cawit Oct. 21, 2020

Oct. 21, 2020

Hi there! I would like to please request for a timezone change on our island please? If you need a reference for this change, please see below link for the legal formal application of DST in Norfolk Island Each year, from the first Sunday in October, clocks on Norfolk Island will need to be moved forward one hour and then back one hour on the first Sunday in April. In 2019, DST will begin at 2am on Sunday 6 October and end at 2am on Sunday 5 April 2020..... http://www.norfolkonlinenews.com/norfolk-island-free-news/introduction-to-d… Thank you very much! Your effort on making this happen is very much appreciated. If you need any more information regarding the matter above, please don't hesitate to contact me. Have a good day! Regards, [cid:image003.jpg@01D69E2D.1FA78EC0] Victor Michael Cawit | Senior Technical Officer - International Communications Norfolk Telecom Norfolk Island Regional Council PO Box 95, Norfolk Island 2899 | 9 New Cascade Road, Norfolk Island T (+6723) 22244 (ext. 115) www.norfolkisland.gov.nf<http://www.norfolkisland.gov.nf/> Integrity | Communication | Accountability | Respect | Excellence IMPORTANT NOTICE REGARDING CONTENT The views expressed in this e-mail are not necessarily those of the Norfolk Island Regional Council unless otherwise stated. The Norfolk Island Regional Council does not warrant that this message is free from viruses or any other defect or error. IMPORTANT NOTICE REGARDING CONFIDENTIALITY This electronic message is intended only for the addressee and may contain confidential information. If you are not the addressee, any transmission, distribution or photocopying of this e-mail is strictly prohibited. The confidentiality attached to this e-mail is not waived, lost or destroyed by reasons of a mistaken delivery to you. The information contained in this e-mail transmission may also be subject to Freedom of Information legislation. If you have received this e-mail in error, please contact the author of the message, as soon as practicable. Please consider the environment before printing.

3 3

[tz-announce] 2020d release of tz code and data available
by Paul Eggert Oct. 21, 2020

Oct. 21, 2020

The 2020d 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: Palestine ends DST earlier than predicted, on 2020-10-24. Changes to past and future timestamps Palestine ends DST on 2020-10-24 at 01:00, instead of 2020-10-31 as previously predicted (thanks to Sharef Mustafa.) Its 2019-10-26 fall-back was at 00:00, not 01:00 (thanks to Steffen Thorsen.) Its 2015-10-23 transition was at 01:00 not 00:00, and its spring 2020 transition was on March 28 at 00:00, not March 27 (thanks to Pierre Cashon.) This affects Asia/Gaza and Asia/Hebron. Assume future spring and fall transitions will be on the Saturday preceding the last Sunday of March and October, respectively. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020d.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 ab21ad9710b88f28995b7ed47c6efda47ffb1be5 dated 2020-10-21 11:24:13 -0700 and tagged '2020d' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 315ce86574780d89482761298137b2871a21cb4391886abdc9f29c6cc09e8b8f6585f96d3f4dfef8d7b54e24720214f5c77144114ad58cc91aa5bbde350c0f9b tzcode2020d.tar.gz 362e4569a666b0776614be3f63f1fe3d5ae259055e7051c9875f36023db9c52b0c5a10c19067114443a4cf2bf92475f8a0aebdf79bac836d967527fcdea4e9b6 tzdata2020d.tar.gz d7e74331d10d17a855363fbae16d55dbf422c1bc3ac4aff56c897d78cea185f16a9342927e292923198bb8a2f4230ca1eb3d23960b44f5c71db153cf83ed3f7c tzdb-2020d.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+QfYEACgkQ7ZfpDmKq fjQONxAAsutVmD1mKngEto0UotZPTOM74RbV11sim+D9PGg04JbQIDUhclmW3Zw7 CAp0QTu0MBs78lA2qugIyv5ma/61LanOA9pcBdjlJ5DA485wAvMCW9deUfK50pTA nzYri3uZ2IwISao4hBWUP7IGQ0fSpbfSiSoxTMcYbNRVWCnDJhfC97SsegMPSN5q 4lPit82uCLIa6s4vk/SuHPFO21TJY5e7DouUG7vkdJRJIX8GUNUMV47IO8cQQUD6 O4Zvsd6ha49iRDJy6mDkIrMpK3r0yC58kZaMXzV++XZA+G4D7sYZbkKnukTGMky/ bB0v2oTIB5BulkM1u1b5/hR0aZ8WlFk6WEDVP6jG+Vvb5rZW4nkOoFI2JjI2vFhZ p0PgzThn8sqUQn2lGbsYA8w7DujKW7nZ5ENFbHhWDm4GHYCRQSTTFU7tHGQbkzqg XFgvYbdPW2er/vpbw5QXSUa3UwdssiXuGUvLMka0aYKPPe5ahAkyE+jDEwoN3K9h e561luc13HwmjOwVxmya4IAomAb+IM4Pt821aKOzELD0epBdk7YmlD0kcqh4LeqR lxawXbLlGQHBAv4DBC58eQNGcP3DaC7fCPhG+cfL9jT1Ygbm8Ncg9ndWZVn5RS1X 7WCqkX9tSFN6CJkd2ozVzoJWjE8NdotdFI05e5Az2zaNmnV6iSk= =/2fr -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+QfYEACgkQ7ZfpDmKq fjR5wxAAjzC37QyQyyLS3GePbM3GAY0kDf40ieCHU9LBEBqTDXFbC8WaMCc+3jQ+ +iaFJbjK6iJeaZLr+y9ea+W47fKmBd0ogW6mR11HiJdmGKncPze1O9aae/thT2UJ KG3FIZYE5hERkyeNMHjwUJqVKcrg5VaE0iuUOlGrwpnNwPQl80zyRWhi0RbMomHR XD7jvMwpTy+x7lEWXA7WLUcxHwY3ezdMjPOwX+9EAVMMNCNEgRSaeBFIo9z3YUnc ppMnQ537TqfvmdvslDc+c6AXI2PqwHBQSluWMNUJHnC8KXdwFB+G2LJRdov7WqdU +dnUKZsGwMxPHqgbNpINf4q48tIg6xEDVXH12973EV1Rh4Tao0g4l18WpFOCXqeI /vNETZHkcqNkhpMb5XI289LU3Mc889RjEjwhpKJv0RN+bw5sRvgftY8j/Vp1Jty0 gHpCA3M1YRglq0SBpfsWpXJsz3T1EcRdT5XToTpG321OsRoymjZ7txqF5siAiWBo P7zGgBe+0mIZ3bSDI/o1a/yuL0jwjTru2SbC6B9maOZXw2iPzEB6j8grFLmsUj7u e/s5jaqYrPTD8PsvBO1r20sP2HwQHhvew+TemVhSuW0yfqifffx0ybwZrw6oF0Ig SEPdSJkwsiOu7U/cKIFuClsZUaiOjjWu9SMWKUNm6AHXpO8CuCk= =48vS -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+QfYMACgkQ7ZfpDmKq fjSyeg//b9pfaBM+EFrf87F1UmgTeSF+s9mtWjuD65z+6QBSr4tHH0sFD00KbYrS F3kaJTvzvxiDlMs/aTSWi7PsXWns9FRa5GKylkkAhTihbkXBAQny7l3em+emZy5t 6PY0MowcLXf3/HoyxMgkXBPxm+U0d9Bv7+yRmvX1WsmyKcbHhn41nw+HUFJNwOW3 mP4RnirQTghvvGJ0eEiWeXtdqzsLyw661SFWZZ/odCpTCYCwSU28boDJmsCMyPcR CM1QcUvPs1YPXWXYYh6f1tl6RGx8sG+4KLFGNwj6Gr5SkUu2tEddMVfJqmRwQNuQ crz0q/R4wuDRnpK4aJMrrW2Vakm6s8CAett1PivMAcH1Rjhceo0JvRUvOUKSyaFc cPZys8qHX/7LfN5SW3Gb12vPBMKrBF8FWGQionD8Ym9p8motCWU8/yoqZBCOjswJ RZiI8yserCWUpauJgLrXQri6DrpGXGyTVIT7kK6zKwnqnrreogkE7K5gQL93qXnw K6EX7UMS/bXfJu8NDwvS/6KcDSnBcCWCpOqe6bynKkgqKlgkF58lStchQN1YDbF1 MXjl6Feq55yAD+YcOb8ZEXZgPbmAo3RChKKLW3SU0Lq3VbjqNZlujvh9ZsaJNMv+ AtsfxLPRxtIeoWKkFR2mRvbqYWPMCrEUvp1pPpFsoFS4pGZPjJ4= =yRLG -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. This is intended to be a temporary transition aid for these parsers. To generate a rearguard-format tarball, obtain the full distribution as described above, and run the command 'make rearguard_tarballs' on a development host. Or you can run 'make rearguard.zi' to generate a single file that can be fed directly to a parser that works like 'zic'.

1 0

Palestine to end summer time on Oct 24th
by Pierre Cashon Oct. 21, 2020

Oct. 21, 2020

The summer time this year started on March 28 at 00:00. https://wafa.ps/ar_page.aspx?id=GveQNZa872839351758aGveQNZ http://www.palestinecabinet.gov.ps/portal/meeting/details/50284 The winter time in 2015 started on October 23 at 01:00. [https://wafa.ps/ar_page.aspx?id=CgpCdYa670694628582aCgpCdY](https://www.waf… http://www.palestinecabinet.gov.ps/portal/meeting/details/27583

2 1

Re: [tz] from tzdata2020a to tzdata2020b: iana, tzupdater, or local issue?
by Paul Eggert Oct. 20, 2020

Oct. 20, 2020

On 10/13/20 2:07 AM, gerar.moisset(a)orange.com wrote: > I'd like to know why we are obliged to patch tzdata2020b-rearguard.tar.gz? It's because TZUpdater uses tzdb internals that are not documented under "Interface stability" <https://data.iana.org/time-zones/theory.html#stability>, and when these internal details are changed, TZUpdater sometimes fails. > For us impact is it breaks automatic tz update. > Does it mean we need to leave this kind of tz update? As noted in <https://mm.icann.org/pipermail/tz/2020-October/029340.html> there will be a workaround in the next tzdb release, which should be reasonably soon, so one option is to wait until tzdb 2020c comes out and try its rearguard tarball. That being said, there's little coordination between the maintainers of tzdb and of TZUpdater, and as far as I know nobody has tested this specific workaround code. (You might be the first one to try it when 2020c comes out. :-) > Does it come from iana src content ? > If not we are not obliged to reply, but I’d like to understand, > does it come from tzupdater, or kind of jdk, or jdk version? It's an incompatibility between tzdb (as published by IANA) and TZUpdater (maintained by Oracle). > tzupdater-2.2.0, TZUpdater 2.3.1 is out, and you might want to update to it for other reasons. However, I expect that it has the same problem here that 2.2.0 does. > openjdk version "1.8.0_191" > OpenJDK Runtime Environment (build 1.8.0_191-b12) > OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode) > > Here is the workaround: > ... > gzip -d tzdata2020b-rearguard.tar.gz > touch pacificnew #empty file > tar -rfv tzdata2020b-rearguard.tar pacificnew > gzip -v tzdata2020b-rearguard.tar Yes, that should work for 2020b. It shouldn't be needed for 2020c and later. > ${JAVA_HOME_OPV}/bin/java -jar ${TZ_UPDATER_JAR} -u -f -l file:///${TZ_DATA_NFS} > $JAVA_HOME_OPV/bin/java -jar ${TZ_UPDATER_JAR} -V|head -2|tail -1|awk -F":" '{print $2}'|awk -F"-" '{print $1}' > > It returns expected result: tzdata2020b This is a strong indication that the workaround should indeed work once 2020c comes out.

2 2

[tz-announce] 2020c release of tz code and data available
by Paul Eggert Oct. 20, 2020

Oct. 20, 2020

The 2020c 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: Fiji starts DST later than usual, on 2020-12-20. Changes to future timestamps Fiji will start DST on 2020-12-20, instead of 2020-11-08 as previously predicted. DST will still end on 2021-01-17. (Thanks to Raymond Kumar and Alan Mintz.) Assume for now that the later-than-usual start date is a one-time departure from the recent pattern. Changes to build procedure Rearguard tarballs now contain an empty file pacificnew. Some older downstream software expects this file to exist. (Problem reported by Mike Cullinan.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020c.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 ab21ad9710b88f28995b7ed47c6efda47ffb1be5 dated 2020-10-16 11:15:53 -0700 and tagged '2020c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: c77fa69d2a005ba7cff602b2267983fd01613f81385bc13c90b9581d69fb0ac73491641cac81e0e5d7dd00ed120c45103859902c2d10da9d25c98b33354f88f7 tzcode2020c.tar.gz bbd66fe236ba0949261cb238bfed454c03b4500b239dc38f1b8fef8d229136f5964c1a8386fe54484e4e5e34a3c28a7b66ee7374ff7e0dd07865d78fc53bf96c tzdata2020c.tar.gz 2b436868e33d9de284a97ec75990995c9ffd8b3086b5d93613b119762492df3d4be79d3e910ba1bbacb005f44d36dca31b72f9d314bafcc23b790628c3dc47ec tzdb-2020c.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+J5IYACgkQ7ZfpDmKq fjT9TxAAs00Q8ggp+GUDbom/Ue9QRiLhTKhoy5mE0mDq0T+4eEVh4T4FH7cO+BEt unSfXYsLUfu0g/Lq9mhj0XMT7n3wKfmGjgrbcx+/s7hd8/ArIT/5gKiJWzhUvotg J67VeHrmR9xJim7qbSGmyxeLJZqlwAsDaKiUWGMqD107RDiw14kYQ2bHHXLVmdJr MBkfAUD81pggsO5WZAvc0iVMNEGQSWvwtszlJRjgeBxBYVV64A8WSHTOz/Js7ZT2 kWW6gPqwr22Z+vXFrX0jGzTtkIk4mzfCunhoB+/pxQnoE5giKXjS3ea2ZPJ3ay/C NVScZAB+ZFqebL4bSrhPdlAqhbRyYG4zcL6gAn5No1oToym3QqhFs1qGhMTOUMVE +kzdFTZmpyXG4r84WSvqCS0adkRQXaOMpt+bwXQCRGpaqBDBwEyljyqWci4kv1si AT+txweOOJPUAshzVlB1uvoLgsGH10FPRJ6rKLl3WWqr6M8IFVwgbjj4vRaKUJX6 en65bTcGdTysQr3ydQJ+CNKhh5KsBvqQuws1pufKfRnptBo/ptnytHvyJ/6Afqkh /NPmRLOwgbxTnQ7ecXF0yKSigrGBStvalhtYwcdkXVPf8yUFeEe/qSQRmpkbFNdO VK/7wo/KViT/RwfCmIk3XUxI54Epw1Ff5vMZOQhUXXNV/kUEl4Q= =oQMm -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+J5IYACgkQ7ZfpDmKq fjQTXQ//ZSpk0iHiwnZqcqujuTh/YWXWvKaWAxRG3sRnz+i6IrrEzsaCrod4yENf 7BSLVrrrNHbAha7S3q/SIIrm2atrEZok/9s7TSa4vIhMASQYY2N+A5DrXcyWYkkE +9SPJH71SKG1MrY2vafr7vgbqXSi9P0LINPjUktUoOj/SS5+DofH6BuMh0f1W6ue VDAnjtlcxxHXVo/lNrKt9xckRNXn7O83QIQmnBTXGh7VhmTBpM2E21DvSk7fmbXG AJ76RxUbz2t0IwSSu6AtP4KrrvoMoltmQM0N0AIWEUt1dcy0q3hIyOB7/J7uJQiQ 0+oDxCBcW1Y2J9X2ZEwzHIZhs1dMvjCRL/PA7aDaSZg5yI6SaovUx8p08/alYUNM fEij8fHcsM4Sy26LDZmd3VHXS5ETY6uRd1jZ+e2X8dZa/oo2wwLsxpxg8cFupc94 vvOHgo/4pQFXAKTNw/bcYi387ixjSrEW9Ap4xNtyZrPUoajhhDMdFlxYhbcg4yGw Mz1G6DJtcAZYn56LfwS2IV9X7bf/0NidzBP+YJrLJ3XTIJHHmsZgypYLgrzd33LZ 7kKx/cT38bPFELKq0OfHttr/Ax7Ed8TEvuVqCjohHodVqxDvWSYpEoYS7gRtmn0p IOPgXEDMuz6ouBKnArE7j4DHGJGX59eoOXIeSbBDbBXmCZ5jxaA= =MSiH -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+J5IcACgkQ7ZfpDmKq fjQOOA//Q/QmUhD/1nqqdOa4fUedkT6Tqv+J2Y1N87IsWht1P7Hza/xJaEBFVkk0 /10Lo9rxh6rBPjYNPiZExqQsqRhXTHX7oFtHT2q5JMFliePzSBp5fY1xhWSPmzYg vlQn+9jdLTl3lLrGI3H7YU+kBABm5t9dgldpv0hXh9mgvEITV/fUZIeevBiQ4zoh 0a8JT8wD5tOzMfchHJUsoLiveEzOSuy3lDcopubSsZug3QJV7saO0KRpNWpk37bs AFlrEgASLKc1XjWt9XHhkXlB3ZhoaKbQ3lKEZuy93Dx4PZOowVchKrC0M1gd2Cq+ YC8B0yufglSCTpzLRKWx6kyPJaeqzTnteSHiU1hKAvk8jKPi9ZizOf8x+bWg8zHk z4YZ9xJ8VVMAYU5S1pi3toZxpNrPlS0jKwUp2fbuk3KriNftkgu/xBEukAR4KqNH 8HGFQ+yyx7yZ+50EBS6fVryGiqmh8c+Jl5LjkLOifaRk6cHCV5cmRNQ6xbxXqDEU zQvxGRYQJRzHcBqboQPl3GkrdNAdo7hmqyohVWjGM9UxLodHc+VsrKNbWJ9R5Q9C +/ZPRtQy6WPTOsPtU5d5ClcOOdxARoZVZlmZAewiN/zGcQ2GfapWbWT5VK8lTYyw 2B7TzqxhIqAqYLXbmfDIeBVGj0FS8IhUol0dWYF+xHgPCoUK3ps= =ZtIL -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. This is intended to be a temporary transition aid for these parsers. To generate a rearguard-format tarball, obtain the full distribution as described above, and run the command 'make rearguard_tarballs' on a development host. Or you can run 'make rearguard.zi' to generate a single file that can be fed directly to a parser that works like 'zic'.

2 1

Re: [tz] Palestine to end summer time on Oct 24th
by Michael H Deckers Oct. 20, 2020

Oct. 20, 2020

On 2020-10-20 18:20, Michael H Deckers wrote: NONSENSE please ignore. Michael Deckers.

1 0

Palestine to end summer time on Oct 24th
by Sharef Mustafa Oct. 20, 2020

Oct. 20, 2020

Hi, As per the palestinian cabinet announcement yesterday , the day light saving shall start on Oct 24th 2020 at 01:00AM by delaying the clock by 60 minutes. http://www.palestinecabinet.gov.ps/portal/Meeting/Details/51584 quote: " . بدء العمل بالتوقيت الشتوي في فلسطين، بتأخير عقارب الساعة 60 دقيقة إلى الوراء، اعتباراً من الساعة الواحدة من صباح يوم السبت الموافق 24/10/2020م. " This covers *Asia/Gaza* & *Asia/Hebron* time zones Thanks Sharef Mustafa

5 8

make rearguard_tarballs fails on macOS
by Deborah Goldsmith Oct. 18, 2020

Oct. 18, 2020

Hi, The change to Makefile for 2020c makes it fail on macOS, as the touch command on Darwin does not have a -d option: > : The dummy pacificnew pacifies TZUpdater 2.3.1 and earlier. > touch -md 2020-10-12T22:53:00Z \ > tzdata2020c-rearguard.dir/pacificnew > touch: illegal option -- d > usage: > touch [-A [-][[hh]mm]SS] [-acfhm] [-r file] [-t [[CC]YY]MMDDhhmm[.SS]] file ... > make[1]: *** [tzdata2020c-rearguard.tar.gz] Error 1 > make: *** [rearguard_tarballs] Error 2 Debbie

4 13

2020c zic code draws complaints from Coverity
by Tom Lane Oct. 18, 2020

Oct. 18, 2020

The Coverity static-analysis tool [1], which is moderately widely used by open-source projects, doesn't much like this: 789 if (bloat == 0) >>> CID 1468262: Incorrect expression (CONSTANT_EXPRESSION_RESULT) >>> "strcmp("slim", "slim")" is always 0 because ""slim"" is compared against itself. 790 bloat = strcmp(ZIC_BLOAT_DEFAULT, "slim") == 0 ? -1 : 1; This is just a bug-finding heuristic, of course, and it won't trouble me that much to ignore the warning. Still, I wonder why it's coded this way and not like, say, #ifndef ZIC_BLOAT_DEFAULT /* Use -1 for slim, +1 for fat */ #define ZIC_BLOAT_DEFAULT (-1) #endif ... if (bloat == 0) bloat = ZIC_BLOAT_DEFAULT; The use of a string doesn't seem to be buying anything in terms of error protection, since the strcmp doesn't distinguish "fat" from "slem" or other misspellings. regards, tom lane [1] https://www.synopsys.com/software-integrity/security-testing/static-analysi…

2 1