- tz - lists.iana.org

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

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

[PATCH] tz-link.html: update Oracle Java tzupdater README URL
by Brian Inglis Oct. 18, 2020

Oct. 18, 2020

Oracle Java tzupdater README URL in tz-link.html has been changed and is currently being redirected; update it in case that does not continue: $ curl -I https://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html HTTP/2 301 server: Oracle-HTTP-Server location: https://www.oracle.com/java/technologies/javase/tzupdater-readme.html ... --- tz-link.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tz-link.html b/tz-link.html index 606a83b9..c8c4e82c 100644 --- a/tz-link.html +++ b/tz-link.html @@ -247,7 +247,7 @@ href="http://userguide.icu-project.org/datetime/timezone"><abbr title="International Components for Unicode">ICU</abbr></a>, <a href="https://developer.ibm.com/javasdk/support/dst/jtzu/"><abbr>IBM</abbr></a> and <a -href="https://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html">Oracle</a> +href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">Oracle</a> Java, <a href="https://www.joda.org/joda-time/tz_update.html">Joda-Time</a>, <a href="https://dev.mysql.com/doc/refman/en/time-zone-support.html">MySQL</a>, and <a @@ -436,7 +436,7 @@ freely available under the <abbr>MIT</abbr> license.</li> <li>Java-based compilers and libraries include: <ul> <li>The <a -href="https://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html">TZUpdater +href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">TZUpdater tool</a> compiles <code><abbr>tz</abbr></code> source into the format used by Oracle Java.</li> <li>The <a -- 2.28.0

2 2

[PROPOSED 1/2] Update Danish URLs
by Paul Eggert Oct. 18, 2020

Oct. 18, 2020

* europe: Update Danish URLs since the old ones no longer work. No need to refer to the now-vanished page of poe (Peter Øhrstrøm) since it was a secondary source anyway. --- europe | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/europe b/europe index af6c628..ea23736 100644 --- a/europe +++ b/europe @@ -1029,17 +1029,16 @@ Zone Europe/Prague 0:57:44 - LMT 1850 # Denmark, Faroe Islands, and Greenland # From Jesper Nørgaard Welen (2005-04-26): -# http://www.hum.aau.dk/~poe/tid/tine/DanskTid.htm says that the law -# [introducing standard time] was in effect from 1894-01-01.... -# The page http://www.retsinfo.dk/_GETDOCI_/ACCN/A18930008330-REGL +# the law [introducing standard time] was in effect from 1894-01-01.... +# The page https://www.retsinformation.dk/eli/lta/1893/83 # confirms this, and states that the law was put forth 1893-03-29. # # The EU [actually, EEC and Euratom] treaty with effect from 1973: -# http://www.retsinfo.dk/_GETDOCI_/ACCN/A19722110030-REGL +# https://www.retsinformation.dk/eli/lta/1972/21100 # # This provoked a new law from 1974 to make possible summer time changes # in subsequent decrees with the law -# http://www.retsinfo.dk/_GETDOCI_/ACCN/A19740022330-REGL +# https://www.retsinformation.dk/eli/lta/1974/223 # # It seems however that no decree was set forward until 1980. I have # not found any decree, but in another related law, the effecting DST @@ -1051,7 +1050,7 @@ Zone Europe/Prague 0:57:44 - LMT 1850 # The law is about the management of the extra hour, concerning # working hours reported and effect on obligatory-rest rules (which # was suspended on that night): -# http://www.retsinfo.dk/_GETDOCI_/ACCN/C19801120554-REGL +# https://web.archive.org/web/20140104053304/https://www.retsinformation.dk/F… # From Jesper Nørgaard Welen (2005-06-11): # The Herning Folkeblad (1980-09-26) reported that the night between -- 2.25.1

2 3

Fiji Daylight Saving Time 2020-2021
by Jashneel Kumar Oct. 16, 2020

Oct. 16, 2020

Dear Support, Please note that Fiji Daylight saving Time has been confirmed as follows: DST Start : Sunday, 20 December 2020, 02:00:00 clocks will be turned forward 1 hour to Sunday, 20 December 2020, 03:00:00 local standard time instead. DST End: Sunday, 17 January 2021, 03:00:00 clocks are turned backward 1 hour to Sunday, 17 January 2021, 02:00:00 local standard time instead. Looking forward to your support to reflect the same in the tz database. Regards, Jashneel Kumar Manager Data Networks & Services Mobile: +679 999 8456 Vodafone Fiji PTE Limited 168 Princess Rd, Tamavua Suva Fiji [Vodafone] ________________________________ The content of this email including any attachments is confidential and may contain information that is proprietary and privileged. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify E-mail Administrator on info(a)vodafone.com.fj Please also destroy and delete this message from your system. Vodafone Fiji PTE Limited does not guarantee that this message is free from computer virus or any other defect. The reader accepts full responsibility for taking defensive and counteractive action needed to rectify the computer virus or other defects caused. Vodafone Fiji PTE Limited : Private Mail Bag, Suva, Fiji | Telephone : +679 3312000 | E-Mail : info(a)vodafone.com.fj Please consider your environmental responsibility before printing this e-mail [X] Vodafone Fiji PTE Ltd <https://www.vodafone.com.fj/>

2 1

2020b not updating with java
by Mike Cullinan Oct. 16, 2020

Oct. 16, 2020

I know this is out of the IANA scope but hoping someone listening can help get the tzupdater tool working again. $ ./openjdk/jdk-15.jdk/Contents/Home/bin/java --version openjdk 15 2020-09-15 OpenJDK Runtime Environment (build 15+35-1559) OpenJDK 64-Bit Server VM (build 15+35-1559, mixed mode, sharing) $ $ ./openjdk/jdk-15.jdk/Contents/Home/bin/java -jar tzupdater.jar -l Using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as source for tzdata bundle. Source directory does not contain source file: pacificnew

5 4

Patch for ziguard.awk
by Neil Fuller Oct. 15, 2020

Oct. 15, 2020

I discovered that the ziguard.awk is not entirely reversible: it doesn't switch between vanguard and rearguard data for Namibia data completely in all cases. Attached is a patch with some more explanation and a proposed fix. It's bigger than strictly necessary because I tidied up the Ireland lines rather than applying the same fix there. Low severity / impact and probably not an issue in the normal release workflow : I discovered it because I was stumbling around generating my own tarballs for testing the proposed 2020b changes. That's not something I usually do. As always, thanks for all the work you do. Neil. -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902

2 2

Ireland considering staying with summer time
by Kevin Lyda Oct. 15, 2020

Oct. 15, 2020

It seems unlikely, but there have been suggestions in Ireland to stay with summer time this year to deal with COVID-19. It's at the tail end of this story: https://www.irishtimes.com/news/health/coronavirus-tighter-restrictions-mul… Out of interest, would a release to support such a change be possible? Kevin

4 3

Re: [tz] Indian Continent
by Guy Harris Oct. 12, 2020

Oct. 12, 2020

On Mon, Oct 12, 2020 at 12:16 PM Bharat Adur <bharatadur(a)gmail.com> wrote: > We find for India there is certain bias taken by some individuals in a country which has such a large population and its Indian Standard Time (IST UT= 5hours 30 minutes), which is accepted by National Physical Laboratory (NPL),New Delhi and Astronomical Society of India. ...and which is the time for the tzdb region with the ID "Asia/Kolkata" - 5 hours 30 minutes ahead of UTC, abbreviation "IST". So the tzdb *does*, in fact, support Indian Standard Time, using the tzdb ID "Asia/Kolkata". > our norm of 1970 cannot be acceptable to Modern India The only "norm" of 1970 is that the tzdb doesn't create new zones for regions that differ *before* 1970. If something changes *after* 1970, we'll add a new zone if necessary. It doesn't mean that the tzdb is inherently out-of-date, with nothing that happened *after* 1970 being supported. > hence its our humble request you to consider IST UT= 5hours 30 minutes. We already considered it and support it, with the tzdb ID "Asia/Kolkata". > and if you desire we can send you at least 50 cities. There are several significant cities in the United States Pacific Time Zone; however, the tzdb has only one entry for that zone, with the ID "America/Los_Angeles". There is no entry with the ID "America/San_Francisco"; even though I live closer to San Francisco than to Los Angeles, this is not a problem for me. There also aren't any entries with the ID "America/San_Diego", "America/Portland", "America/Seattle", etc.. The tzdb does *not* create multiple entries for a given zone so that every city in that zone appears in a tzdb ID for a zone. A good time zone selector will allow the user to specify a city name and will look up the tzdb ID appropriate for that zone, e.g. for Bangalore/Bengaluru, Delhi, Mumbai, etc., it will select Asia/Kolkata.

2 1

Re: [tz] Indian Continent
by Jonathan Leffler Oct. 12, 2020

Oct. 12, 2020

Thank you for your response. I note that your message didn't go to the tz(a)iana.org mailing list. I've copied the list again with this message. I have no official status on the team that maintains TZDB; I'm merely an interested observer. Therefore, anything I say can be overridden by that team. But I believe I'm following the "party line" on the topic. I'm not clear what your response is claiming. Are there 50 different sets of rules for different cities in India for changes in time zone since 1970? Unless there are different time zone rules for different areas of India, one entry does for all of India. Whether I like it or not (and I don't), America/Los_Angeles is the official name for the time zone in all of California, even the bits that would rather Los Angeles didn't exist. To have the remotest chance of success, you will need to persuade those who maintain the TZDB that there are different time rules for different parts of India since 1970-01-01. You can look through the mailing list archives to see other people's request for similar changes that have been denied for similar reasons. Occam's Razor (https://en.wikipedia.org/wiki/Occam%27s_razor) comes into effect: Entia Non Sunt Multiplicanda Praeter Necessitatum (Do not multiply entities unless necessary). Adding more city names would be multiplying entities without good reason. If you wish to create historical information for different time zones in India before 1970-01-01, then you may have some luck, but you'd need to provide the data, with references to official or authoritative sources of information about the different time zones. But that becomes more specialized — it might not make it into the main TZDB distribution because the time zones within India have not diverged by location for the last 50 years or more. On Mon, Oct 12, 2020 at 12:16 PM Bharat Adur <bharatadur(a)gmail.com> wrote: > Dear Sir, > We find for India there is certain bias taken by some individuals in a > country which has such a large population and its Indian Standard Time (IST > UT= 5hours 30 minutes), which is accepted by National Physical Laboratory > (NPL),New Delhi and Astronomical Society of India. our norm of 1970 cannot > be acceptable to Modern India hence its our humble request you to consider > IST UT= 5hours 30 minutes. and if you desire we can send you at least 50 > cities. therein. > With warm Regards > Bharat Adur > > On Mon, Oct 12, 2020 at 10:44 PM Jonathan Leffler < > jonathan.leffler(a)gmail.com> wrote: > >> The way the TZDB works is that if all areas of a country have used the >> same time rules since 1st January 1970, there will be a single time zone >> entry for that country. >> >> Are there any parts of India that have not used the same time rules as >> Asia/Calcutta (Asia/Kolkata?) since 1970-01-01? If not, there is no reason >> to introduce any new zones. If you have an application that wishes to >> provide alternative names, then you may. It is not recommended that the >> names in the database are shown to end users in any case. >> >> This is discussed in the theory.html file distributed with the TZDB data. >> >> >> On Mon, Oct 12, 2020 at 8:47 AM Bharat Adur <bharatadur(a)gmail.com> wrote: >> >>> Dear Sir >>> Indian is very large country with over 130 billion population with 28 >>> states and over fifty major cities including Mumbai. >>> However in your catalog list for India in tz list , we have only as >>> Asia/Calcutta. >>> Can you kindly introduce in python in tz it should locate the place and >>> th local time, >>> with best regards >>> Bharat Adur >>> >> >> >> -- >> Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> >> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org >> "Blessed are we who can laugh at ourselves, for we shall never cease to >> be amused." >> > -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

DST changes in Hungary (full historical revision)
by Nyáry Géza Oct. 12, 2020

Oct. 12, 2020

Dear Paul! I examined it all of the Hungary daylight saving time changes. More differences I found what I repaired and I prepared it it source file, which I attach to this letter. I used Library Hungarica online database as a source, where from scanned contemporary ministerial decrees, instructions, newspapers and from other documents it was possible to find the time of the changes concerning the years. https://library.hungaricana.hu I checked the modified changes many times and I considered it right. If it's possible, I ask the exchange the attached modified Hungarian section in global database! Thank you very much! Bets regards, Géza Nyáry

5 11

Indian Continent
by Bharat Adur Oct. 12, 2020

Oct. 12, 2020

Dear Sir Indian is very large country with over 130 billion population with 28 states and over fifty major cities including Mumbai. However in your catalog list for India in tz list , we have only as Asia/Calcutta. Can you kindly introduce in python in tz it should locate the place and th local time, with best regards Bharat Adur

2 1

Bug in tzdata version (2020b)
by westmail24＠yandex.com Oct. 9, 2020

Oct. 9, 2020

Hello, After compiling now I see that tzdata version is "8675a", not is "2020b". It's your bug or bug of "my" program now? (Screenshot in attachment.) Please check/fix it. Thank you. -- Andrew Oct. 9, 2020

4 3

Fiji Day Light Saving
by Raymond Kumar Oct. 8, 2020

Oct. 8, 2020

Hi Paul Please find attached gazette for DST changes in Fiji. It is from December 20th 2020, till 17th January 2021. Thanks Raymond Kumar Head of Billing & Products +6797015315 ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.

4 3

Re: [tz] tz Digest, Vol 109, Issue 8
by Alan Lehotsky Oct. 8, 2020

Oct. 8, 2020

I’m a little tardy in upgrading (last installed 2018g), but this 2020b release has tar files without a root directory, so when I carelessly did a tar -xzf tzcode2020b.tar.gz tar -xzf tzdata2020b.tar.gz they overwrite each others files instead of unloading into respective directories ./tzcode2020b and ./tzdata2020b. Maybe this isn’t a change in behavior and I just forgot that it happened to me back in 2018. Alan Lehotsky https://codegentllc.com

2 1

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

Oct. 8, 2020

The 2020b 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: Revised predictions for Morocco's changes starting in 2023. Canada's Yukon changes to -07 on 2020-11-01, not 2020-03-08. Macquarie Island has stayed in sync with Tasmania since 2011. Casey, Antarctica is at +08 in winter and +11 in summer. zic no longer supports -y, nor the TYPE field of Rules. Changes to future timestamps Morocco's spring-forward after Ramadan is now predicted to occur no sooner than two days after Ramadan, instead of one day. (Thanks to Milamber.) The first altered prediction is for 2023, now predicted to spring-forward on April 30 instead of April 23. Changes to past and future timestamps Casey Station, Antarctica has been using +08 in winter and +11 in summer since 2018. The most recent transition from +08 to +11 was 2020-10-04 00:01. Also, Macquarie Island has been staying in sync with Tasmania since 2011. (Thanks to Steffen Thorsen.) Changes to past and future time zone abbreviations and DST flags Canada's Yukon, represented by America/Whitehorse and America/Dawson, changes its time zone rules from -08/-07 to permanent -07 on 2020-11-01, not on 2020-03-08 as 2020a had it. This change affects only the time zone abbreviation (MST vs PDT) and daylight saving flag for the period between the two dates. (Thanks to Andrew G. Smith.) Changes to past timestamps Correct several transitions for Hungary for 1918/1983. For example, the 1983-09-25 fall-back was at 01:00, not 03:00. (Thanks to Géza Nyáry.) Also, the 1890 transition to standard time was on 11-01, not 10-01 (thanks to Michael Deckers). The 1891 French transition was on March 16, not March 15. The 1911-03-11 French transition was at midnight, not a minute later. Monaco's transitions were on 1892-06-01 and 1911-03-29, not 1891-03-15 and 1911-03-11. (Thanks to Michael Deckers.) Changes to code Support for zic's long-obsolete '-y YEARISTYPE' option has been removed and, with it, so has support for the TYPE field in Rule lines, which is now reserved for compatibility with earlier zic. These features were previously deprecated in release 2015f. (Thanks to Tim Parenti.) zic now defaults to '-b slim' instead of to '-b fat'. zic's new '-l -' and '-p -' options uninstall any existing localtime and posixrules files, respectively. The undocumented and ineffective tzsetwall function has been removed. Changes to build procedure The Makefile now defaults POSIXRULES to '-', so the posixrules feature (obsolete as of 2019b) is no longer installed by default. Changes to documentation and commentary The long-obsolete files pacificnew, systemv, and yearistype.sh have been removed from the distribution. (Thanks to Tim Parenti.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020b.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 47311d42a3ad6a8afa95d1f63fa8b6bb2710b16e dated 2020-10-06 18:35:04 -0700 and tagged '2020b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 04849f196430717962cbeedf11bbba592c304eaff5d67350c936af83dc8e8cb4cedc1c5f461c984aef05124d6c0f13a874789dff77b85a4b399faf80d75537e0 tzcode2020b.tar.gz 27ade698e61881e637ab04834633595cfbdb08fd97177e9731093165d1268a64dffa0570b5e137b9daa4374e6c6827ed01c476074ec61ec0b9a44a7f23479be9 tzdata2020b.tar.gz 475f69b908f8d7d777fcf93f1d223fc4af404a3c8caaa678ca97702a3e9c1ec3e1b5747c8688dfc7b291300bab9ff4804b8ceebfc2de47b505cffe4fa5594abc tzdb-2020b.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl99HSkACgkQ7ZfpDmKq fjRNrBAApj2R+iRJs5UdW5lIdsANGSz3d9l/dMs48Ryk5SU6qBCVtL4cKavSfw5Q Xh6ZaohNc8GPHF4pGTHBBrKwq6lxQgbemSXswqh+Qi4584wlI5zHr2J7ohLJTnnx ma4EgRCEBplU7XnANa/dQEr69DVG1LkgvOFNGS42oNNcS5zIVcLkeQaJ93MI/tJO seHQTmQn5hiKsZ60S+qrPy4Yu4Cwxzo6Le/BVEXE3leVAFMcXMzRvV4UEooh2TCM b7v2cHnTKKdN7iTzmKyYrXh3Xs1ENVECLS9D9d9mXDT6FViIXcx95StSELXH3i/s eqqpgnAcpPQIb16uIrT+XlzGbJ56HNh2j/axVqaVzkwHlEOKz7b7y7OUfUUNpzD+ vI/uZ/0reUs2rr0IeSHLK3LVRbPvcw/sHQN8EjirSXVDQcfjAr0x72V+YPzDIQ5K fQ6o1ADrrd6cHCa90D1xz94d34DD3sSfUjaOOpNpaLJL7GW5CNsm0CaWIc8my4Dp Agt6T4QtA0WAtsnvupKk3tuPP57rvrlVTQYEvfhpDsPxVkY+R80ir/3+eCMZHrvm 3CZ1uWNGd7kG1m4sfcq0AHUl3bgHapJkLRtyMY4izQJZIm0pGEsrCi8P3+87wDgU eIMcGJUYOjTtE1ELGWxzo066FpOLMoGm9YOwN+FYi+eSjEdjGdg= =BKe9 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl99HToACgkQ7ZfpDmKq fjT5CQ//W6kd+vP2tAdMbmJnH35sCd0NoAFBC1j00Blg+I6s507w5VjOTjvrvjlE 0RB2G67vNKTOBybPyk7l8cKq+5Xw5IE1xqwqfpN3+DH2BWt4P0AllcBBRRky9iXS oO+z4F51rud9+CD2vbhtx0eT9MWYVfzrncNUHIYm7sDx01vtCp3h5u9ryB2sfHT/ iMKrB5ytFqWkNXZtMiRDj3LZF0y2+JM1/8lfZB/hyxx1Bbvcm07dQvBBz8ljT6KD /BJFsgwvvlpxOZ1P0fFb7BnMPD5v/fB5r/0i/c4ErIY8JPtxDY6ctGdtbC/0H7Xf kjve+Fue08CBg4tXEW75SvWBP8Li1XylSNohIEtnclXj9B1nwu0WArZtATIqhpxl T77J85JkVQoAi5Wh38Msy9QWb54FRoK8/c1drfwb/iMkRYt57mU5zuY9JJvx7mAm S3eVqU3/tX4Ue7gQ1hjW3m9abmS1Hmq4aQ8r1uS0t2cIjbrMY2zaRwYzb2UknT2w VVr5O5bWoPHSFDeqUU7NdGHQzJX+NLvpTlcvJHXONSu7CksC09uhzBVJ2LbkjQS1 zD+jSCTgXZonegcF0/UsfMrxmrizDFVcvwDXnDa4TcRPVSevtdWvM+EXr3Dto0N/ wlI4v2nZE2ZFB3+7iGxc0WwiHUdsVbQVD+fCTIBl4Uh4ViTAsXI= =/O2G -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl99HTsACgkQ7ZfpDmKq fjRCtQ//ZOBneEAY4W08oOJ3UipwG+Xq33arMbZ86yBBBrkjUIfcLFi7ESPGvkn8 zAR28fYpL7kUTQyuzMjwIxdFSDpgmRUpLRtlLn+Vdkx1o/WCbj5A0O3nsqq+M04J yuGr1dYGfTnGi624mvsB5dPxneGw9TCh9YseBKV+hF6FxmhdBkl1Gwxz4fyzAdo9 A4OQhtnKntZo6Peuo8ittfnA6fi6hwVZjeaqjGWMN7qEjSOG79mVAHaKxsOKUs2L Mnre/1iRQX/33c/hJHrleit2+H430WCVJ3WGQ0OjODfnrl5B9tmWv0CFIaJTUq4Q zwOBpa2CvTd0hOmagZiP7PuTI1AXjMpJBd1ISssbw1mPO7lcAjSfjYMYy972xhUQ pig67kaKATh8tfPUTUjE8pEOyLnPkZdT0dbFqz1Sqad2u1y5NmWl1ps8YYZl9hHC a0pzxRD7HIK4o1BYuSMLuvwgfdFFjBeGMbm1/sFOSgRzzrZQ8BIXEmNG5whM+OQF +cfmyG9VZimvAI/vcw2w6xqokJn/l8yrG8D3GJZNA4s3xJTLYXUc6qrY7FpTDa0A Ce2Lj1HZN4q9FyIeEU22YAXKDmP8/7eNCO/Z7I9mrjocbpS09tL2YOWh1EI1Gq/U fqxprHL5w+/AKehKr5YZ7eZA5QXQBH80RIXqntJwFsnkd7pfmYU= =1NiW -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, this release's data entries can be turned into a rearguard-format tarball that does not use these features. 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'.

4 5

Removing systemv, pacificnew, Rule TYPEs, zic -y
by Tim Parenti Oct. 4, 2020

Oct. 4, 2020

I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references. Of course, I was only looking at systemv in the first place because I'd also recalled that we're still distributing the pacificnew file, which has caused some confusion every so often and has likewise generally outlived its usefulness. This led me to the related file yearistype.sh, which is also unused, except as a default script to pass to the Makefile to process the TYPE field of Rule lines. Given that the TYPE field hasn't been used by tzdata since 2000f and has been more formally deprecated since 2015f, the whole unused feature is ripe for "spring cleaning". The attached proposed patch 0002 completely drops support for the TYPE field (marking it reserved for compatibility purposes) and causes non-trivial use of the field or use of zic's -y option to error (instead of warning as it has since 2017c). It also removes the pacificnew and yearistype.sh files that are no longer needed and updates documentation accordingly. I don't presently foresee any need to repurpose the nullified field down the road, but this is the next step in allowing us to "reclaim" it in the event that such a need should arise in the future. -- Tim Parenti

3 3

Converting tz-how-to.html to HTML 5
by Paul Eggert Oct. 4, 2020

Oct. 4, 2020

On 10/3/20 3:49 PM, Tim Parenti wrote: > (the VALIDATE=':' is because my MacBook > doesn't have nsgmls). The VALIDATE stuff in Makefile is needed only because I hadn't bothered to convert tz-how-to.html to HTML 5 with validator.w3.org checking, like the other web pages. I installed the attached proposed patch to do that, removing the need for VALIDATE etc. This is for maintenance convenience; it doesn't change the content of that web page, or its appearance on my Firefox 81 browser.

1 0

Updating zic.c to further match Link line field names
by Tim Parenti Oct. 3, 2020

Oct. 3, 2020

In working on my latest proposed patch, I also noticed an outdated error message in zic.c which referred to the FROM field of a Link line. We had updated these field names in comments and documentation in release 2014g to be more descriptive and readily understandable like the parameters of 'ln': https://github.com/eggert/tz/commit/78e3924ea43079a0f3333677a728e0f0ed679cd3 The attached proposed patch further updates the zic.c code to more consistently use these new names throughout. This mostly affects the naming of parameters and locals, but a few macros and struct fields are also updated for consistency. -- Tim Parenti

1 1

Casey time zone change
by Steffen Thorsen Oct. 2, 2020

Oct. 2, 2020

Based on information we have received from the Australian Antarctic Division, Casey station and Macquarie Island station will move to Tasmanian daylight savings time on Sunday 4 October. This will take effect from 0001hrs on Sunday 4 October 2020 and will mean Casey and Macquarie Island will be on the same time zone as Hobart. Some past dates too for this 3 hour time change back and forth between UTC+8 and UTC+11 for Casey: - 2018 Oct 7 4:00 - 2019 Mar 17 3:00 - 2019 Oct 6 3:00 - 2020 Mar 8 3:00 and now - 2020 Oct 4 0:01 Best regards, Steffen - timeanddate.com

2 3

Re: [tz] [IANA #1173666] Time zone change - Yukon Canada
by Andrew.Smith＠gov.yk.ca Sept. 30, 2020

Sept. 30, 2020

Good day. I work for the Government of Yukon in Canada. We are in the process of revising our definition of time to be permanently on UTC -7, no longer observing a twice-annual time change. I was on the hunt for authoritative standards related to time, and saw the IANA come up as caretaker of the time zone database, which appears to be relied on for software and systems. I am contacting you to see if there is any process beyond notification to making this adjustment in your TZ database, and perhaps to know if there are other agencies that should be aware of what Yukon is planning. From what I see now, TZ database names "America/Dawson", "America/Whitehorse" and "Canada/Yukon" would be affected by this change. Our regulation is not yet complete, so it is not law at this time and I am not looking for immediate change. We are aiming for finalization here by November 1, 2020. Hope to hear from you soon. Andrew Andrew G. Smith Intergovernmental Relations Executive Council Office Government of Yukon C: 867-335-6008 -----Original Message----- From: Amanda Baber via RT <iana-questions(a)iana.org> Sent: July 2, 2020 3:48 PM To: Andrew.Smith <Andrew.Smith(a)gov.yk.ca> Subject: [IANA #1173666] Time zone change - Yukon Canada Dear Andrew, Thank you for contacting us. IANA hosts the Time Zone Database, but the database is managed by the Time Zone Coordinator in conjunction with a mailing list. You can find find mailing list information here: https://www.iana.org/time-zones This document should have or point to much of the information you're looking for: https://data.iana.org/time-zones/tz-link.html As is noted at the link above, "If your government plans to change its time zone boundaries or daylight saving rules, inform tz(a)iana.org well in advance, as this will coordinate updates to many cell phones, computers, and other devices around the world. With less than a year's notice there is a good chance that some computer-based clocks will operate incorrectly after the change, due to delays in propagating updates to software and data. The shorter the notice, the more likely clock problems will arise; see https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%… for examples." Best regards, Amanda Baber Lead IANA Services Specialist On Thu Jul 02 22:20:44 2020, Andrew.Smith(a)gov.yk.ca wrote: > Good day. > > I work for the Government of Yukon in Canada. We are in the process of > revising our definition of time to be permanently on UTC -7, no longer > observing a twice-annual time change. > I was on the hunt for authoritative standards related to time, and saw > the IANA come up as caretaker of the time zone database, which appears > to be relied on for software and systems. I started with ISO 8601, but > couldn't see the full text to know if there are time zone standards > there. I am contacting you to see your TZ database is a widely adopted > and authoritative as it seems, to see if there is any process to > making this adjustment in your TZ database, and perhaps to know if > there are other agencies that should be aware of what Yukon is > planning. > From what I see now, TZ database names "America/Dawson", > "America/Whitehorse" and "Canada/Yukon" would be affected by this > change. > > Our regulation is not yet complete, so it is not law at this time and > I am not looking for immediate change. We are aiming for finalization > here by November 1, 2020. > Hope to hear from you soon. > > Andrew > > > [cid:image003.png@01D65084.40C16690] > > Andrew G. Smith > Intergovernmental Relations > Executive Council Office > C 867-335-6008 | Yukon.ca

10 23

Python PEP-615 release eminent
by Matt Johnson-Pint Sept. 21, 2020

Sept. 21, 2020

Just a heads up. Python 3.9.0 is scheduled for release in two weeks on 2020-10-05

3 4

Europe/Kyiv
by Ihor Romanyshyn Sept. 14, 2020

Sept. 14, 2020

Hi there! It's possible to add an alias "Europe/Kyiv" for russian name "Europe/Kiev"? For more information about this please read https://en.wikipedia.org/wiki/KyivNotKiev -- Ihor Romanyshyn Network Administrator *Avenga* 118b Antonovycha Str 79057 Lviv Ukraine office +380 67 670 5051 <+380676705051> mobile +380 93 957 5136 <+380939575136> mail ihor.romanyshyn(a)avenga.com www.avenga.com Avenga - Transforming Industries

2 1

looking for information about changing time zone
by Françoise Kerjouan Sept. 11, 2020

Sept. 11, 2020

Madam, Sir, Im living in New Caledonia; our local government is thinking about changing time zone (from UTC +11 to UTC +12). Could you please tell me how long a lead notice should be to be sure that the international community will get and process the information ? I understood that the ICAN TZ database is widely used, but I didnt catch if it is also used for international transports (by airports for example). Could you please tell me if it is the case? If not, whom should I ask for? Best regards, Françoise Kerjouan

5 6

Question] Regarding Asia/Yerevan timezone abbreviation
by Goun Lee Sept. 10, 2020

Sept. 10, 2020

Hi, I'm Goun from South Korea. I have a question regarding Asia/Yerevan timezone abbreviation When I checked the following line, https://github.com/eggert/tz/blob/master/asia#L127 it's written as 4:00 Armenia +04/+05 As far as I know, Armenia has no DST time, so the abbreviation should +04. isn't it? I'm just wondering if it's correct or not. best regards. Goun

2 1