- tz - lists.iana.org

Re: [tz] CCTF survey on Time and Frequency Metrology - Telecom
by Gertsvolf, Marina Jan. 25, 2021

Jan. 25, 2021

Dear Colleague, The last time the definition of the SI second was changed was in 1967 when Caesium atom hyperfine frequency transition was chosen as the reference value. Since then first the primary thermal beam caesium clocks and then caesium fountains have been providing the SI second realization values to steer the International Atomic Timescale. The current fountain uncertainties are at the low 1E-16 level. The frequency metrology research in recent years has surpassed the microwave clocks, and optical frequency standards based on trapped ions and atoms now provide frequency measurements with evaluated uncertainties at the level 1E-18. The frequency comparisons have also been advancing both through improved techniques in Global Navigation Satellite Systems signal analysis and the Two Way satellite Time and Frequency transfer as well as with fibre based frequency links and portable optical clocks. Frequency combs used to compare frequencies between clock lasers of different optical clocks and also between optical frequencies and microwave 133Cs frequency of 9.192631770 GHz are now routine laboratory equipment and are commercially readily available. These factors now provide a solid foundation to prepare for the redefinition of SI second based on the optical frequency standard. The exact approach is currently under discussion and it may be selecting one atomic candidate or building an ensemble. The specific requirements and the conditions for the redefinition to take place are also being finalized. The Consultative Committee for Time and Frequency (CCTF) has started preliminary work on this subject, to investigate possible scenarios and their possible impact. It is within this framework that we contact you an expert in the field of Telecommunications, in order to make sure that the needs and wishes of your community are integrated into the general debate that will take place and may, eventually, lead to the redefinition of the second. With the new definition, the frequency measurement accuracy will surpass that of Caesium-based timescale by at least one order of magnitude and will provide an adequate tool for current and future research into fundamental physics as well as technology exploitation. The redefinition is not expected to affect any of the existing commercial frequency standard uncertainties such as those of caesium beam clocks or hydrogen masers, because their uncertainties are generally orders of magnitude higher than the expected accuracy of the new definition. Same is true for caesium fountains. The computation and dissemination of UTC will also not change, but UTC will become more stable and accurate based on the improved optical realizations of the SI second. We would like to ask your expert opinion on whether the redefinition may have any impact be it negative or positive on your field of study and operation. The issues we would like you to consider are not just scientific and technological, but also regulatory and legislative. Your answers will be carefully examined and taken into account by CCTF in their analysis of Time and Frequency metrology current and future needs and SI second and UTC evolution. You can find the survey at https://www.surveymonkey.com/r/CCTF_Survey_2020 and in the attached letter from CCTF president Noël Dimarcq you will find additional information on other activities at CCTF for your reference. Best regards, The CCTF Task Force on the redefinition of the second, subgroup A Co-chairs: Marina Gertsvolf (marina.gertsvolf(a)nrc-cnrc.gc.ca<mailto:marina.gertsvolf@nrc-cnrc.gc.ca>) Gaetano Mileti (gaetano.mileti(a)unine.ch<mailto:gaetano.mileti@unine.ch>) Secretary: Frederic Meynadier(frederic.meynadier(a)bipm.org<mailto:frederic.meynadier@bipm.org>)

5 4

[CCTF_survey on Time and Frequency metrology]
by Patrizia TAVELLA Jan. 25, 2021

Jan. 25, 2021

Dear Colleague, in December you should have received the announcement of a CCTF survey (see below) aiming to understand the needs and the opinions of the time and frequency community. Please remind that the deadline for the survey is January 31, 2021. This is an important possibility to contribute to the future way forward on some hot topics. Thanks to those who have already answered. Your contribution is really appreciated. Best wishes for the new year Dear Colleague, the Consultative Committee for Time and Frequency (CCTF) is currently working on very important topics concerning the field of Time & Frequency Metrology and its applications. They are: 1. Updating the Roadmap for the redefinition of the second 2. Leap seconds in UTC - building a consensus for a continuous timescale 3. Promoting the mutual benefit of UTC and GNSS 4. Sharing resources to improve international timekeeping To make sure that the needs and wishes of concerned institutional bodies and stakeholder communities are integrated into the general debate, we have prepared specific questionnaires, that we kindly ask you to answer. Your answers, opinions, and ideas will be carefully examined and taken into account by the CCTF in order to provide future guidelines and recommendations. Please find attached a letter explaining the process. Thanks for the contribution you can give to this survey. Please feel free to forward this email to other colleagues in your field that may give useful feedback, and please apologize for multiples emails you may receive on this topic. with sincere appreciation, on behalf of the CCTF, Noel Dimarcq CCTF President Dr Patrizia Tavella Director of Time Department Bureau International des Poids et Mesures Pavillon de Breteuil 12 bis grande rue 92312 Sèvres Cedex Tel : +33 (1) 45 07 7076 Email patrizia.tavella(a)bipm.org<mailto:patrizia.tavella@bipm.org>

1 0

[tz-announce] 2021a release of tz code and data available
by Paul Eggert Jan. 24, 2021

Jan. 24, 2021

The 2021a 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: Changes to future timestamps South Sudan changes from +03 to +02 on 2021-02-01 at 00:00. (Thanks to Steffen Thorsen.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2021a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2021a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2021a.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 336c8f8262e31116878b079abba80b1626baaa8f dated 2021-01-24 10:54:57 -0800 and tagged '2021a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: bf1d53bcbfecd3b09d57a9e6d3cb49b5dc5f8e1b6674b67e7f974e1a268c2aaf13ca89a7ef12f49d0665aff782bd72685e00c22a41ca88a028da0429f972fd45 tzcode2021a.tar.gz 7cdd762ec90ce12a30fa36b1d66d1ea82d9fa21e514e2b9c7fcbe2541514ee0fadf30843ff352c65512fb270857b51d1517b45e1232b89c6f954ba9ff1833bb3 tzdata2021a.tar.gz 1878ec039db73d3255d808e2b28a5acf2b384d4c5d178aaa2048b5b73cd6b34d03c2ab7282ed615d286b695fa46c628d7e4b6fb6f84bf1905ac8dfbb740769c1 tzdb-2021a.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmANxdIACgkQ7ZfpDmKq fjRy5g//Y/CPFNFyrlCJSvZT8pP5f+qGfntGfUGEXBJRdFNmGW8KU/wRLHrK+mEP 8VQgPKZqYaKQwJvVTrDycs96Ntm62sKbzb/tSr04JvxYYcJa4ecvMISI8ePI/M9m sKNoKLDuok/Dnl9yntvDWFjLkw43TBMqZRj+oXxMz9Ui8Cap4iZFZfw+tgedwjUk 8mkd45xLQJ5D9k9K6bXvgy0KIFvhN7+Td16do94QHx86gaiSwgzey81rqetzHisb fj329dq2xMa+5bKxS8QDfbL05HOrxQBKmgJQNl2E7MvonBbXAjrd56FQJjGkaViM cTwhQecrElm9bPIzNduV2zy6CyE+5ZlQcYrUJ73g4pH1kZ7H4S5UdIL0O8sdcDOW Gjj0xUMGdwUpI0k2VkKvMjKQ1LzT/vKZy0S4n2LlHTOtIifUA5SigQ1tPmQuWwW+ XfbDb2reeq1mUzphHvwsakKOSPRfwVeszfN4lgOmh3hOpPvEEkzEhQYVOKYwBvEr sK+zl0a+c3ePOMioC9uUF56B38bRgVcTojA/suaoMJEH8IE8wLBT4dSEjofA0wya kKVpvHZiwTj5mM7bMVgq+gtvaQprI52k/X6HWcBD4CcL0dOMQswmz8Sv2LGd7IFK oFm30G2vBVIzprcKdeezYU83EAeUnASbDt5kPm5PCnzELmgRu4E= =pUNC -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmANxdIACgkQ7ZfpDmKq fjTnYRAAnozc58/XHxdZ92os3TIzGZHDt4jWZt7zeSlzag7C9r0pvq2u0K0AZVPG yGMUpNlFm2fcbks65En8+wRVZ/5AJeEkUA4V2DDMlf5yDtiXZyt42YTu0UL/saZ3 wHEZIPySeZWKdUILp9BTD9ZDmY2VbIceL1PGMfs00Ti98UgmsNG8yJPMD2E86T3H dcsx7kTYFou9KYuvm3GDlxrQO7X/sTVVEnWJF7Z8rLQz4wjPnYn6Lspoav+N0HNR ycRXSADS3c2kjlaeRjjYVKaekJ3oIXvWgfXcYb1CcB59bACDi4HOMvd8kMU/PV5R p7lkZpSvSNNy/5j5MJDV79YVBwas5++yjv8bQZPkDnS/1YvW9I8ca4YYeTGEA1/G 89sysUlUEYzuojs+oApgqFFAwl+Eo0y5MLyOuRxcXgWw6+eTW6oHHaUXLDFq9jwR d0biMlHIFZNyKHZ72dUbSLo8FalHspHdRYBCppwU8cCprJlPc43zuljru86jRYuW jr228IpKq75ngtXbOHexVrnJejCp/NuV3rcfP3FjC2C3HC2Ao95FO9xT0ZlcTpXq +wu2wZ8csf1RO/hzyOHtcpuFZBRL5a4ZQNvqydFgMgfx2oZcSIAz3GmA8qt5BjHQ C+JwBd00A4JvOigUMvprSSvu3OEOv2kCLgAQSJPOSGWbkrr0s08= =5dc0 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmANxdQACgkQ7ZfpDmKq fjQKOg//RWKxqgAHjfiurbEV8E4KJfA1FCN9lnj8Yd0y5r7QXmABKpJvTa//oqy1 s6OvcAlw9KtBx69F5AR8O3/cJSK8ITKTApoYBDoOhPxBQBYkWAg5tM5Eajv0nOlm HlsnKi0jR/vTyDEhBl4XX/dqzcQF0qb0dmdd+Bm5aB3VjeYC5RlebizT5BHEjTtB 2kw/fkoWYt9r9x+drLwTTDeKB2P7PGZiiOsru5sReWJd5liH/htgC9oC8j4vmbKC BnAFAoRtOYiazAJmyc/da4PJXHEBPnsL9iBxGLR265kkn6rg1v+SJhsBQm5Xj3Ci zwDsX4+93Uk2ezU/Eyk+zvIhKIWWWjcSdWa4zVjLROBvX9jQ1xBSFcTN1mBXccEg pbu9U29qISOY11RqtenC++1KXdNFlLdWiNvuLNNYmSRPOVSyfz+h57wkXqj3zlSS MAH6xGdIGH043pofOgmrVkgyywJ8C195ajmgjQoG5CxCf/o1YgBgoJyd07xPZlEv D94ZShvuXMDHtQ7eJOoFcVTOcIRj5WvEmxxup4eEDmFULOQ2RrVphYTkpVApp5ks kQVPxDkANq7cNwBDokuzV9cDX+ScnSEMs7k79TMB1S2szuM/W8g2ZTN2wwQoZq4T 8QMKHQPMTU72IesC38+bn7V2dHxR14jT+tpjVZc3FsguILd7Ev0= =o/OB -----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

[PATCH] Update web links
by Paul Eggert Jan. 24, 2021

Jan. 24, 2021

* tz-link.html: Remove broken links and links to expired drafts. C++20 is now official. Replace CIA time zone map link to a more-general link, as the old link’s replacement has a long cookie-like component and is possibly unstable. --- tz-link.html | 45 ++++++++++++++++----------------------------- 1 file changed, 16 insertions(+), 29 deletions(-) diff --git a/tz-link.html b/tz-link.html index 56ef9e4..abe38d8 100644 --- a/tz-link.html +++ b/tz-link.html @@ -352,12 +352,7 @@ transferring time zone data by reference. <a href="https://devguide.calconnect.org/Time-Zones/TZDS/">TZDIST implementations</a> are available. The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis -mailing list</a> discussed the Internet draft <a -id="TZDIST-Geolocate" -href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate">TZDIST -Geolocate Extension</a> (now expired), which let a client determine its timezone -from its geographic location using a <a -href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>.</li> +mailing list</a> discusses possible extensions.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> Internet Calendaring and Scheduling Core Object Specification (iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) @@ -410,11 +405,11 @@ transition in the <code><abbr>tz</abbr></code> database.</li> <li>The <a href="https://howardhinnant.github.io/date/tz.html">Time Zone Database Parser</a> is a <a href="https://en.wikipedia.org/wiki/C%2B%2B">C++</a> parser and -runtime library with API <a -href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html">adopted -into the draft standard</a> for +runtime library with <a +href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html">API</a> +adopted by <a href="https://en.wikipedia.org/wiki/C++20">C++20</a>, -the next iteration of the C++ standard. +the current iteration of the C++ standard. It is freely available under the <abbr title="Massachusetts Institute of Technology">MIT</abbr> license.</li> <li><a id="ICU" href="http://site.icu-project.org">International Components for @@ -627,11 +622,6 @@ It is freely available under the <abbr>GPL</abbr>.</li> implementations contain a copy of a 32-bit subset of a recent <code><abbr>tz</abbr></code> database in a Go-specific format.</li> -<li><a -href="http://users.skynet.be/Peter.Verthez/projects/intclock/">International -clock (intclock)</a> is a clock that displays multiple time zones on -<abbr>GNU</abbr>/Linux and similar systems. It is freely available -under the <abbr>GPL</abbr>.</li> <li>Microsoft Windows 8.1 and later has <code><abbr>tz</abbr></code> data and <abbr>CLDR</abbr> data (mentioned <a href="#CLDR">below</a>) used by the @@ -677,10 +667,7 @@ licenses</a> to <code><abbr>tz</abbr></code> contributors.</li> is Astrodienst's Web version of Shanks and Pottenger's out-of-print time zone history atlases <a href="https://www.worldcat.org/oclc/468828649">for the US</a> and -<a href="https://www.worldcat.org/oclc/76950459">for the world</a>, -now published in <a -href="https://astrocom.com/astrology-products/software/acs-atlas-software">software</a> -form by <a href="https://astrocom.com">ACS-Starcrafts</a>. +<a href="https://www.worldcat.org/oclc/76950459">for the world</a>. Although these extensive atlases <a href="https://astrologynewsservice.com/opinion/how-astrologers-contributed-to-the…">were sources for much of the older <code><abbr>tz</abbr></code> data</a>, @@ -704,11 +691,13 @@ gives current time zone rules for airports served by commercial aviation.</li> <section> <h2 id="maps">Maps</h2> <ul> -<li>The <a href="https://www.cia.gov/index.html">United States Central -Intelligence Agency (<abbr -title="Central Intelligence Agency">CIA</abbr>)</a> publishes a <a -href="https://www.cia.gov/library/publications/the-world-factbook/graphics/ref_ma…">time -zone map</a>; the +<li>The <a +href="https://www.cia.gov/the-world-factbook/maps/world-regional/">World +and Regional Maps section</a> of <em>The World Factbook</em>, published by the +<a href="https://www.cia.gov">US Central Intelligence +Agency (<abbr +title="Central Intelligence Agency">CIA</abbr>)</a>, contains a time +zone map; the <a href="https://legacy.lib.utexas.edu/maps/world.html">Perry–Castañeda Library Map Collection</a> @@ -734,7 +723,9 @@ where the two differ greatly. It's a bit out of date, unfortunately.</li> <section> <h2 id="boundaries">Time zone boundaries</h2> <p>Geographical boundaries between timezones are available -from several <a href="https://en.wikipedia.org/wiki/Geolocation">geolocation</a> +from several <a +href="https://en.wikipedia.org/wiki/Internet_geolocation">Internet +geolocation</a> services and other sources.</p> <ul> <li><a href="https://github.com/evansiroky/timezone-boundary-builder">Timezone @@ -883,10 +874,6 @@ of Legal Time in Germany</a>.</dd> <dd>The Interior Ministry periodically issues <a href="ftp://ftp.cs.huji.ac.il/pub/tz/announcements" hreflang="he">announcements (in Hebrew)</a>.</dd> -<dt>Italy</dt> -<dd>The National Institute of Metrological Research publishes a -<a href="http://oldsite.inrim.it/res/tf/ora_legale_i.shtml" hreflang="it">table -of civil time (in Italian)</a>.</dd> <dt>Malaysia</dt> <dd>See Singapore <a href="#Singapore">below</a>.</dd> <dt>Mexico</dt> -- 2.27.0

1 0

South Sudan to change time zone?
by Steffen Thorsen Jan. 20, 2021

Jan. 20, 2021

Quite a few sources, but they seem mostly to be syndicated from the same story tell that: "South Sudan will change its time zone by setting the clock back 1 hour on February 1, 2021, the government spokesperson has said. According to the minister of information, Michael Makuei Lueth, South Sudan will change its offset from UTC+3 to UTC+2." from https://eyeradio.org/south-sudan-adopts-new-time-zone-makuei/ and a bit different here: https://radiotamazuj.org/en/news/article/south-sudan-to-change-time-zone-ne… Best regards, Steffen Thorsen - timeanddate.com

5 8

Kyiv NOT Kiev
by Vyacheslav Lukin Jan. 18, 2021

Jan. 18, 2021

Hello, My name is Viacheslav Lukin and I live in Kyiv, Ukraine. Could you please change incorrect spelling Kiev in database to correct Kyiv? Campaing #KyivNotKiev: https://en.wikipedia.org/wiki/KyivNotKiev Wikipedia and Google use the spelling Kyiv: https://en.wikipedia.org/wiki/Kyiv https://www.google.com/maps/place/Kyiv In Ukraine use the spelling Kyiv: https://static.ukrinform.com/photos/2015_10/thumb_files/630_360_1443988512-… https://static.ukrinform.com/photos/2019_02/thumb_files/630_360_1550082358-… https://static.dw.com/image/49169749_303.jpg Ukrainian companies use the spelling Kyiv: https://kyivstar.ua/ https://www.kyivpost.com/

2 1

Rename timezone
by Вітя kor0p Jan. 18, 2021

Jan. 18, 2021

Hello, I'm from Ukraine, and I want to change the name of Europe/Kiev timezone to Europe/Kyiv, because it's the right translation of the capital of Ukraine. Some countries, media, and organizations start using the correct name. #KyivNotKiev. The wiki article about this: https://en.wikipedia.org/wiki/Kyiv With hope to changes, Victor

2 1

Negative leap seconds in mainstream media
by Arthur David Olson Jan. 12, 2021

Jan. 12, 2021

"Why Scientists Want to Shorten the Minute to 59 Seconds" https://www.popularmechanics.com/science/a35165130/leap-second-shorten-minu… (As noted on Twitter by Molly Conger, @socialistdogmom.) @dashdashado

8 10

No leap second on 2021-06-30
by Tim Parenti Jan. 9, 2021

Jan. 9, 2021

Per IERS, Bulletin C 61 (2021-01-07) https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.61 …and forwarded below. A patch updating leap-seconds.list from NIST is attached, and is installed in the development repository. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Thu, 7 Jan 2021 at 08:05 Subject: Bulletin C number 61 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 07 January 2021 Bulletin C 61 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2021. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0

Europe/Kiev to be renamed to Europe/Kyiv
by Андрій Лавріненко Jan. 8, 2021

Jan. 8, 2021

Good afternoon! I'd like to report that the spelling of this Ukrainian city name has been changed from Kiev to *Kyiv*, as reflected by Google Maps <https://www.google.com/maps/place/%D0%9A%D0%B8%D1%97%D0%B2,+%D0%A3%D0%BA%D1…>, Wikipedia <https://en.wikipedia.org/wiki/Kyiv>, the UN <https://www.un.org/Depts/Cartographic/map/profile/ukraine.pdf>. Hope that will be useful to inform the tz name update. -- Best regards, Andrii Lavrinenko

2 1

zic bug: Wall-clock ordering of transition times
by Tim Parenti Jan. 4, 2021

Jan. 4, 2021

I noticed a bug while incorporating changes to commentary for the Turks and Caicos Islands… https://mm.icann.org/pipermail/tz/2020-December/029609.html Our contemporaneous use of "3:00" in the UNTIL field for the 2018-03-11 change intentionally avoided two clock changes in a row (first from 01:59:59 AST to 01:00:00 EST, then from 01:59:59 EST to 03:00:00 EDT an hour later). https://github.com/eggert/tz/commit/8792d7bed2c684cf842592fd7779645f335a33f6 My recently-added commentary clarifies the reasoning behind this and concludes that the order was likely intended to take effect from 03:00 -04, once the Eastern US had sprung forward, and not at 02:00 -04 as the text suggests. However, I noticed that using "2:00" in the UNTIL field instead doesn't actually result in the expected extra transition: --- to2050.tzs 2020-12-05 14:11:12.000000000 -0500 +++ to2050new.tzs 2020-12-05 14:17:31.000000000 -0500 @@ -5201,7 +5201,7 @@ 2014-03-09 03 -04 EDT 1 2014-11-02 01 -05 EST 2015-03-08 03 -04 AST -2018-03-11 03 -04 EDT 1 +2018-03-11 02 -04 EDT 1 2018-11-04 01 -05 EST 2019-03-10 03 -04 EDT 1 2019-11-03 01 -05 EST It seems that, the 02:00 wall-clock time having already been approached once for the transition out from AST, zic assumes that the transition specified in the US Rule at the same wall-clock time has also taken simultaneous effect in Eastern Time, although in reality it wouldn't yet for another hour. In this case, the wall-clock times of these two transitions are identical, while in actuality the transitions are meant to take effect sequentially. It appears that this bug also manifests in other cases where the strict ordering of transitions does not exactly match the strict ordering of wall-clock times: Trying out "2:30" in the UNTIL field should mean that the Zone transition should happen 30 minutes BEFORE the US Rule would take effect (and thus require two transitions), but by wall-clock time, it would "appear" to be 30 minutes AFTER (fooling zic into thinking only the "latter" Zone transition is needed as the Rule would have "already" taken effect). And, indeed, the results are similarly incorrect here, too: --- to2050.tzs 2020-12-05 14:11:12.000000000 -0500 +++ to2050new.tzs 2020-12-05 14:36:07.000000000 -0500 @@ -5201,7 +5201,7 @@ 2014-03-09 03 -04 EDT 1 2014-11-02 01 -05 EST 2015-03-08 03 -04 AST -2018-03-11 03 -04 EDT 1 +2018-03-11 02:30 -04 EDT 1 2018-11-04 01 -05 EST 2019-03-10 03 -04 EDT 1 2019-11-03 01 -05 EST Certainly an edge case in this particular instance, but given that many historical transitions coincide tightly with transitions in other regions being "joined" or "left", perhaps one worth a further look. -- Tim Parenti

5 16

No Scottish time zone in the 1990s
by Clive D.W. Feather Dec. 30, 2020

Dec. 30, 2020

An interesting (for us on TZ) little bit of history. https://www.bbc.co.uk/news/uk-50950961 "National archives: Sir John Major snubbed separate Scottish time zone" -- Clive D.W. Feather | If you lie to the compiler, Email: clive(a)davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

1 0

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

Dec. 29, 2020

The 2020f release of the tz code and data is available, reflecting the following change to the build procedure: 'make rearguard_tarballs' no longer generates a bad rearguard.zi, fixing a 2020e bug. (Problem reported by Deborah Goldsmith.) There are no changes to the data since 2020e. The build-procedure change was circulated on the tz mailing list and is intended for downstream consumers that can process only rearguard format. Please see the PS at the end of this email for more info about rearguard format. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020f.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 846c3ac7abc246094dd754ac6dc90423148a5107 dated 2020-12-29 00:17:46 -0800 and tagged '2020f' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 5f6bf1b508434842eb9dacacc744b5f3375c35b88e401ef372b5fde80ad2f523484fe52a6e99460e402230406ebf6a9261a97efde45a610f8e8085893d55c4ed tzcode2020f.tar.gz dd312def18c807452fda2e697514e2064c5f51ebdbedd0cfe6f231252c76ee5d4409f653b295ed5657b7d30b868690047fdb70a10942e69eaa40b77473e3f9ca tzdata2020f.tar.gz a2efd9cb6308c75de382ff1ddc524dad5da10d76d86c6bf41ab2f979fffae1356b2599b3fcc045eab1cb56b16f9371663da5be57c1f43591517be62e65abbf1c tzdb-2020f.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/q5ukACgkQ7ZfpDmKq fjSOqA//d2SuaDA9HEXuGXOgTV2f9Iu8x4XF3cIc/UYIh/9yi7T1jVhRD70rPjTO 0g1ohBPoT/oY5OaFholMuZfoIwNgPv2K4c05xNrmNdbbz/3iaddm1zpD5WutRw2c u+hqrR1C5p/ICoSEH+/SAwmBFYEpQYCnkFUScC7YeGoZzzpKls3l/8hvUFaKt8SW ssgS/nVA3L54W8Hdu8WUl2Nz7xmkN3zzRseZMsU3+CrUwXtGzyySZPAJR1Ryk1ee PgwZaoteeGFl08Y7QfvyZBc7xakgnMEdhFB+m2SH//RO6DLjjuWlSAV9wMCk6dZq Uu3yZDVfsV91kiXOavdZFGXQCGXFVmkU7cZnSlpGWuIQGDX0iLOdcuWTFSEw+Av6 UP0cKyX2gJdXaqsYaBpgkCNh0SzG8ui5sS+vimCXG0+0d3z5ru2sHOTSkDxAke6a Jbs5PCz4HXpkIbbE73j+GzaoGWvbzqIledXV+J18uOAcfX13Ejft1nMFyZYh2vvJ 3DH3j1KA0NMs1u9o2F3HWPQcGZKuLFg0BxU2hEeIqbEwXAs980Mo5xrDtFRk4VLy Sg/o6XiREeXV06gXLqlP0vKa+qf88J9u18wMuuiPX1NmNZOcdekVVZtYQ5VhDjbZ xcg3S7YG9HUB+SxnAWQ21jaioQPLYB0Sc2/2vo8VzvIDE9iy8FI= =WeIr -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/q5ukACgkQ7ZfpDmKq fjQ8ug//WH7DpYFvSYMKpSj6gG0m5lK0JXcs062EKGQNsVoUjSVImu3VPbpUS9tu cO3NCUmeqTmwhUOuZQN2qGAT2KyNhcLTlza8xuRQm/tJ7SYpArseY9rudQtkjbCi uWELQi5+a6CA/PBBRJzDJwQPTf4wDZr24vDd29tKqBho5T5cisudXHhqh1Bm0Bfr NPyPsS6+oLJofIVsU0I5V+fbnU98ny5I1r/OyVIJgAlvEcb0kMDr0fBfu1dNvJI9 Tyl3kvdLSMCgf/lRXEFYJpI0RuUeIAsOvHaSwSCHKGc7FHzgDiK1U5D/4z5Ipo02 0AQKkLFkEbzwou/5KtX2Q3+yba1AGu64C7elu+aKepUNGhkzAaJrl2xNNM25Sdn4 1WvxOt43GTIze0cr9UHm942sU5UxH0ahv4h9pEbqJ44UVzBhuDDqcMXYJEWhdhMf 6dgRA7SJThuX7tN758to9Ze9XyXMdzAPdJKs/wyLrRGyDq0dXlRTVPL4Nk9ZqRQh FYJlOhM2TGSg7VsNgn8gneODaaQJpJ7jVSIwicQtWES2K2oblrFz4LSeXm39xZDc 0JRNh/fSeRygCGrjD7CLqq88UGTxhEuZbEXKXSPMLC+7j7JF/CmCVj8HjNw8M3Cy uk/Tfamala66AGltxPwKchTPBJH8F4tZy+4krfYXByoIX5h+Ta4= =Fk0g -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/q5usACgkQ7ZfpDmKq fjSp4A//aoSQ/VDoYZhE5F7PXV+td9DTVGABdA6ubQppymgX8uJvuBgk46pDRmVw Yba4dVcblTzjbCNDCBf9+nkgj46hGdql10t9bjgBDKf5MVQwp8hDyQfj3qbJciBD E0JSMXw3JQpuK1YVqxTXldINxtaSaLJUhYh1inBmEs8uX+vrwzURmYhF7NLoG7GL ymClE3BAJwkNXuRJ4tAMhEaANdShnre+uJWWW7DeNZPrHVKhSSD7IyAWin3vNUEj FA3ELERWgTVbkpmsUUH+5VtUIp8dE9jGxzgaPfy4KmuN0D4qiEgjSg23AFZDWqwF jDX2OlQl7J9oQfeUUBooee1S6IkVCC0+WNJPhSjeeKV8CUBBT5YKtTAgnx14bgkc nL01dF49WxA2MrQMWd794jh6dpMwDzdWw4gdEMLoiSOKRpO5E5iHzjM7c0WWyrGl Hqh6ZmBZz+17wBFSd7QQtLpwWajl+yGgSONJcw0cnvdjleJ6m89vcdzsrsD55ONT uRZK1TEaZqYG6U6lk/XxDsVQiC1CQ9/vWOPT8bhd2wdIhf9g0skN+MNachKQfs11 9Xn+pfMk79Vgatbbq9rDk0F3v6gRjayYRDtcVCFoOmrdXWmRhQtvyerm6wCILsFU gWpdS8tIo/4dwbypyot/5fe0ZEUBJGfbe7PSZu7a64DTgecE5R8= =mWt8 -----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

Joda-Time compiler broken again
by Stephen Colebourne Dec. 28, 2020

Dec. 28, 2020

The latest 2020e release broke the Joda-Time compiler again. https://github.com/JodaOrg/joda-time/runs/1607329443?check_suite_focus=true… Presumably, some rule now contains a 31 in a 30 day month now? Stephen

5 8

[tz-announce] 2020e release of tz code and data available
by Paul Eggert Dec. 27, 2020

Dec. 27, 2020

The 2020e 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: Volgograd switches to Moscow time on 2020-12-27 at 02:00. Changes to future timestamps Volgograd changes time zone from +04 to +03 on 2020-12-27 at 02:00. (Thanks to Alexander Krivenyshev and Stepan Golosunov.) Changes to past timestamps Correct many pre-1986 transitions, fixing entries originally derived from Shanks. The fixes include: - Australia: several 1917 through 1971 transitions - Bahamas: several 1941 through 1945 transitions - Bermuda: several 1917 through 1956 transitions - Belize: several 1942 through 1968 transitions - Ghana: several 1915 through 1956 transitions - Israel and Palestine: several 1940 through 1985 transitions - Kenya and adjacent: several 1908 through 1960 transitions - Nigeria and adjacent: correcting LMT in Lagos, and several 1905 through 1919 transitions - Seychelles: the introduction of standard time in 1907, not 1906 - Vanuatu: DST in 1973-1974, and a corrected 1984 transition (Thanks to P Chan.) Because of the Australia change, Australia/Currie (King Island) is no longer needed, as it is identical to Australia/Hobart for all timestamps since 1970 and was therefore created by mistake. Australia/Currie has been moved to the 'backward' file and its corrected data moved to the 'backzone' file. Changes to past time zone abbreviations and DST flags To better match legislation in Turks and Caicos, the 2015 shift to year-round observance of -04 is now modeled as AST throughout before returning to Eastern Time with US DST in 2018, rather than as maintaining EDT until 2015-11-01. (Thanks to P Chan.) Changes to documentation The zic man page now documents zic's coalescing of transitions when a zone falls back just before DST springs forward. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020e.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 efc5c061920f1d5820d66b7ec88ebff144c55b3f dated 2020-12-22 15:14:34 -0800 and tagged '2020e' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 37656ee4400f6e7ac8b3d4b515ea2ae940de05e8a95873112a4ec08afc11227214f269e4ef1bedb0389497958dd07a6d4721191e441920bc45c235b029a8a885 tzcode2020e.tar.gz 1e64b5c91b9e56923cf8e3e079781c59c8afb6c379b38b9b91ef493929814d50c29a6368cfcf77db08a7af3b6876387bac5617f64ac965a5bddab436d17862c4 tzdata2020e.tar.gz 77e62a3717d179b13f35710dedd87d780649edf6c338c056e41ba58d49225e512074a5fbfa3ae52242bea6b28d1a08bb0e2b07ff7a3aed031dc9d357dac34170 tzdb-2020e.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/ifpwACgkQ7ZfpDmKq fjQrYA//Z3ky92YK4p8GAejA/69W92B2n+uATB7YPOVJXjWOieo+nmlJihEaY447 bxsLfrExy/AwM5wUoqu9JPQmjUGQYxQR0MjIdpzLeWNCGx+NM8n2j+9K00VXxIXX 356rhSNclm5a/1AmkeeDeYK1C8Fw3QIQnaqeTMHDZ/Txv2UncAMshHR2P+9c2i/k N5A+XK0X3+YNHs/0AHbFobRonynw68cogTeSdslMxFtjWV1iTNNR7c8hHHCDXMgJ sjF7hJ7d6RHBRDQn53XgJdR/OKPaj1RJXncP1Be9j6J1M5wepkHJFVS7/66dDl+g 7TyimxnE/y5gxNVk1JWF9ssz31ksGBRbwq1P8IdF3/EsNF3tTB3eqmKM7PB55Oiu k9MWSDo5/fjfdhH24oYUhocJmMN+n2iiBjAh+mWOq1KNPBGtugbztSZPNXuHDHn9 vsAVuuOdK7FvZcbzE0kMqh3gCmp1YBPcXUSnlqLGaowwlykfoYYR0MGz8AdvJreE 5Su2wfiPlI/B2zvVmJ1i2LFr+9nfVFWlmXGAwFmHunpEKTHB9b0HKXVdsJL9qZC2 Gm7SXPMzHEjZ1G420jT8Bx0qfGLC62jTq98QSK6BdcfLd0AsU+rstmQviFZOtSAv qEPrAXPXUraEwMs2/dR+eXR0DWQMEbUWgtmxJM3jHOGnWRseAQc= =xaDL -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/ifpwACgkQ7ZfpDmKq fjSC+w/9HzW/PbI7gfxfbPkF0fCyHCl2OWWrLlJi1m0G72balJ+BmkhI3vvnBGwK 3OKhvN/HOxA4d11JpXiYmPuQ7iuCDO8nRTDWbtg5nuEdP3FOJqUBD0HKDjTg/UUo haXoFxJwPklPqGOiIsFklEQWgVwpN+LwZkL7b2yjjadL0k5ukx6z/G2lJ5qF2i63 f3Gbe/oG/UYd3ERlDpjvgn2tJWfmoS0S3qU3Y9TpraL3NrmunnbtIFDW7SIEM2oP W4XmtkNgBQGlHS1/x/vocNo31h6KyzqVg6OSyvk88Fzp8vE+gHGOVTLR2RdNh/0H NQDi+Pj65KlIJUsjcLmZo+Huv+eNUfzwBcG+LGwUhay0q+2kaeGTs6epohYFNZen A/0/nzXJBohqcBnbLcBYVf+AZUHuPs5lTkG3OZpdRSvkmw6lELlJbBQMEf/HP/kG l43x9DEe0Dr2oDIEr1mfjszFJqKvSg43QJnTgUJtd0SqITazC1N9XuIZj0uXJ64g zfC1aByJ1FLNJmkMDKbl+OzVg7o53sS2gzL/EaGp43NeOPVa84w5MSWdZnuPz8xa 8KDdcaqWeY+mdLonfq5K/DZhOcV6UanBEXFFrmGZymSSqF2zYPpzPBB/7+B29S5F 68v8ScTY8a3fKjhQqrqzNOOKbVMSwM7m8dZ5o69nIW/knvdmxeg= =eekA -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/ifp0ACgkQ7ZfpDmKq fjQnxA//ZYROGBW1B1b7EY+j8b8z8oBsrzuN+PHkpmXqXre/rVJfIU7NoRoOoZ27 U3JDYPhQ6jy3fOCkW8Xa/eBwEe9PXfBnlpjAYbQ4d7KUvxzDauNG7Sch/aOKuQqE LIM9B+Gdyojn1dAimKcVh8z+lSH3f+gaL3/kCDAPDCJqxsDpbnzQ5rsgpf7OlkG8 6yBRo4wNsW6D49nEVScCPwtmlMQUBFesV0J49rZ74NL9eArIjjdHgwSSc0RtSTLx VT8yDmV1ZW93W4+ZKwfnyPb/u8w8O5NP42SoWHOdXV40UpyU/jWfioKPhbLr+D1R AU+uPE/GBpIPEd6dL75WNMQWvSPkER+QEcTYdzJIMiqOpwUXEADn5/miH3JiJ1Cx rgkQuukOzmmshL3YiKxWM2WT41NdVZn4MrXx3TfS2gw0Am4zElkRwcNanFc7Ksyl PNoJrypAKPnArG3+P0LSFxq9nQUsaajlYcAqYthRtzTicPA13iXWml/ATh1sw36H rJAEAVBg2TmIHo4/zlEuV7alrnBT0tIz38RtGvGA7lVB0w8ZLrh3BqyezucoK3Zc GsleX8wkJrrWMcdVPnRUCfCosx8IN57349mnL2g5v1B3Ij/ytYy4yDr8H7/vAX2c ddaxW1aluGBzL48ZKKJedDP/vZgRWINXMAyEyqdXW2G33aMsFlw= =IS+h -----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'.

4 14

Daylight saving time in Argentina
by Pol Dec. 24, 2020

Dec. 24, 2020

I have some inconsistencies in the database regarding some time changes in Argentina. I would like to know what is the possibility of corroborating and making these changes. To give just one example, 03-06-1993 Buenos Aires, Argentina would still be GMT -2 (due to the time change from -3 to -2 that took place on 10-18-1992) and the return to -2 occurred just the next day (03-07-1993). Thanks in advance Pol Neiman <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Libre de virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 1

Time zone and UTC
by Jacques Grillet Dec. 24, 2020

Dec. 24, 2020

Hello Do you propose a database to download ordered by UTC with 2 columns If not, where is it possible to have this data UTC | Time zone name Thank you Meilleures salutations, Jacques Grillet M. 079 219 17 78

2 1

tzdata-latest.tar.gz tarball points to tzdata2020d
by Kiran Ravikumar Dec. 23, 2020

Dec. 23, 2020

Hello, Looks like the latest(tzdata-latest.tar.gz) release tar bundle points to tzdata2020d - https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz. Can we get it updated to tzdata2020e? Thanks, Kiran

2 1

Re: [tz] Volgograd is planning to change its time zone back to Moscow on December 20, 2020
by Paul Eggert Dec. 23, 2020

Dec. 23, 2020

On 12/2/20 2:57 PM, wtz wrote: > (State Duma plan to pass the Bill in the second and third reading next week - > around December 9, 2020) Thanks for keeping us up-to-date. After December 9, it'll still need a look-see by the Federation Council and a signing by the president before it's a done deal. Not much time before the time change on December 20. I suppose people will just use "Europe/Moscow" if their tzdb copies aren't updated in time. Your source says "в скандальном вопросе" ("v skandal'nom voprose"), a curious choice of words. The extreme lack of notice is scandalous from my point of view, and perhaps the source is making the same point.

6 9

[PATCH] Improve doc of zic coalescing zone+DST transitions
by Paul Eggert Dec. 22, 2020

Dec. 22, 2020

* zic.8: Improve documentation for how certain transitions are coalesced. Also, use current data for America/Menominee instead an America/Grand_Turk entry that not in current data. Improvements suggested by Tim Parenti. --- zic.8 | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/zic.8 b/zic.8 index 2273dad..60262d7 100644 --- a/zic.8 +++ b/zic.8 @@ -590,35 +590,41 @@ first transition into standard time. In a single zone it is an error if two rules take effect at the same instant, or if two zone changes take effect at the same instant. .PP -If a continuation line subtracts from the UT offset after a transition that -would be interpreted to be later if using the continuation line's rules, the +If a continuation line subtracts +.I N +seconds from the UT offset after a transition that would be +interpreted to be later if using the continuation line's UT offset and +rules, the .q "until" -time of the earlier zone or continuation line is interpreted according -to the continuation line's rules. +time of the previous zone or continuation line is interpreted +according to the continuation line's UT offset and rules, and any rule +that would otherwise take effect in the next +.I N +seconds is instead assumed to take effect simultaneously. For example: .br .ne 7 .nf .in +2m -.ta \w'# Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'max\0\0'u +\w'\*-\0\0'u +\w'Mar\0\0'u +\w'Sun>=8\0\0'u +\w'2:00\0\0'u +\w'SAVE\0\0'u +.ta \w'# Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'2006\0\0'u +\w'\*-\0\0'u +\w'Oct\0\0'u +\w'lastSun\0\0'u +\w'2:00\0\0'u +\w'SAVE\0\0'u .sp # Rule NAME FROM TO \*- IN ON AT SAVE LETTER/S -Rule US 2007 max \*- Mar Sun>=8 2:00 1:00 D -Rule US 2007 max \*- Nov Sun>=1 2:00 0 S -.ta \w'Zone\0\0America/Grand_Turk\0\0'u +\w'STDOFF\0\0'u +\w'RULES\0\0'u +\w'FORMAT\0\0'u +Rule US 1967 2006 - Oct lastSun 2:00 0 S +Rule US 1967 1973 - Apr lastSun 2:00 1:00 D +.ta \w'Zone\0\0America/Menominee\0\0'u +\w'STDOFF\0\0'u +\w'RULES\0\0'u +\w'FORMAT\0\0'u # Zone\0\0NAME STDOFF RULES FORMAT [UNTIL] -Zone\0\0America/Grand_Turk \*-4:00 \*- AST 2018 Mar 11 2:00 - \*-5:00 US E%sT +Zone\0\0America/Menominee \*-5:00 \*- EST 1973 Apr 29 2:00 + \*-6:00 US C%sT .sp .in .fi -Here, an incorrect reading would be there were two clock changes on 2018-03-11, -the first from 02:00 AST (\*-04) to 01:00 EST (\*-05), -and the second an hour later from 02:00 EST (\*-05) to 03:00 EDT (\*-04). +Here, an incorrect reading would be there were two clock changes on 1973-04-29, +the first from 02:00 EST (\*-05) to 01:00 CST (\*-06), +and the second an hour later from 02:00 CST (\*-06) to 03:00 CDT (\*-05). However, .B zic -interprets this more sensibly as a single transition from 02:00 AST (\*-04) to -02:00 EDT (\*-04). +interprets this more sensibly as a single transition from 02:00 CST (\*-05) to +02:00 CDT (\*-05). .PP A link line has the form .sp -- 2.27.0

1 0

Re: [tz] Europe/Volgograd timezone changes in Russia
by Novoselov, Iliya Dec. 22, 2020

Dec. 22, 2020

?Hello, We're writing you on behalf of Russian software developer - Nexign, and all of its clients. Your IANA DB is used in our products as an industrial standart. The reason of this email is that Russian government is about to decide to change the Europe/Volgograd timezone from +4 to +3. This is going to affect our software and our customers, so we would like to know: 1. Are you aware of this changes? 2. Has the patch of IANA DB been planned already? If not, what should be done for that to happen, and how can we help? --------------------------------------------------------------------- Iliya Novoselov Teamlead, "Tariffication" Domain, Saint-Petersburg city Maintenance and Support Department nexign iliya.novoselov(a)nexign-systems.com<mailto:iliya.novoselov@nexign-systems.com> nexign-systems.com ---------------------------------------------------------------------

5 7

Ontario moving to permanent DST? Perhaps someday.
by Tim Parenti Dec. 5, 2020

Dec. 5, 2020

The Legislative Assembly of Ontario has passed a bill which would advance standard time in the province by one hour and repeal the seasonal clock changes — effectively putting the province on year-round daylight saving time. https://globalnews.ca/news/7485079/ontario-daylight-saving-time-amendment-a… According to MPP Jeremy Roberts, who introduced the private member's bill, the legislation would require "coordination" with neighboring jurisdictions such as Quebec and New York state, and "would not come into effect until the Attorney General decides it should come into effect." Indeed, the text of the bill states that the act "comes into force on a day to be named by proclamation of the Lieutenant Governor", who represents the Canadian monarch. The bill passed the assembly unanimously on its third reading and received Royal Assent on 30 November 2020. https://www.ola.org/en/legislative-business/bills/parliament-42/session-1/b… https://www.ola.org/sites/default/files/node-files/bill/document/pdf/2020/2… -- Tim Parenti

1 0

Volgograd is planning to change its time zone back to Moscow on December 20, 2020
by wtz＠worldtimezone.com Dec. 2, 2020

Dec. 2, 2020

The State Duma approved (Nov 24, 2020) the transition of the Volgograd region to the Moscow time zone. According to Draft Federal Law N 1012130-7 "On amendments to article 5 of the Federal law" "On the calculation of time" Nest step is approval by the Federation Council and the President. If approved by the the Federation Council and the President, this Federal Law 1012130-7 will enter into force on December 20, 2020 See reference links below: https://sozd.duma.gov.ru/bill/1012130-7 http://docs.cntd.ru/document/566418247 The State Duma approved the transition of the Volgograd region to the Moscow time zone. https://gorvesti.ru/society/gosduma-progolosovala-za-vozvrat-volgogradskoy-… Volgograd oblast (Volgograd) is going to change its time zone back to Moscow time (from UTC+4 (MSK+1) to UTC+3 (MSK)) on December 20, 2020 https://www.worldtimezone.com/dst_news/dst_news_russia76.html Regards, Alexander Krivenyshev, WorldTimeZone.com

4 4

Some time zone history (1)
by Paul Eggert Dec. 2, 2020

Dec. 2, 2020

> The Determination of the Time Ordinance, 1919 commenced on 1919-11-24. Thanks for catching my typo; proposed patch attached and installed into GitHub. > Also, the Defence (Revocation) (No.4) Regulations, 1945 commenced on 1946-01-06. True, but how would that affect tzdb? As I understand it, those regulations <https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA256> repeal DST, but on 1946-01-06 Gold Coast was already on standard time (having switched from DST on 1946-01-01). Hence on 1946-01-06 there was no clock transition, merely a change in which regulation was in force.

2 2

From (ISO3166-1 alpha2 + ISO3166-2) country+region code to timezone?
by Joseph Ernest Nov. 30, 2020

Nov. 30, 2020

Hello, How is it possible to get the timezone for a specific datetime and a (ISO3166-1 alpha2, ISO3166-2) pair, i.e. a country code + region code ? Example: ISO3166 -> TimezoneDE-BE -> Europe/Berlin AU-TAS -> Australia/Hobart or Australia/Tasmania US-NY -> America/NewYork Thank you in advance,Jo PS: I have seen the file "iso3166.tab" but this is only for country codes, i.e. the first part of ISO3166.

3 2