October 2020 - tz - lists.iana.org

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. 22, 2020

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