- tz - lists.iana.org

TIme in Belize
by P Chan Nov. 13, 2020

Nov. 13, 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. 27, 2020

Oct. 27, 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