- tz - lists.iana.org

[PATCH] URL housekeeping
by Paul Eggert March 12, 2022

March 12, 2022

* tz-link.html: Omit no-longer-active projects, and update URLs. Mention "pytz: The Fastest Footgun in the West". --- tz-link.html | 33 ++++++++++++--------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/tz-link.html b/tz-link.html index 48724ad..92da48f 100644 --- a/tz-link.html +++ b/tz-link.html @@ -89,7 +89,6 @@ title="Berkeley Software Distribution">BSD</abbr></a>, title="Web Operating System">webOS</abbr></a>, <a href="https://en.wikipedia.org/wiki/IBM_AIX"><abbr title="Advanced Interactive eXecutive">AIX</abbr></a>, -<a href="https://en.wikipedia.org/wiki/BlackBerry_10">BlackBerry 10</a>, <a href="https://www.apple.com/ios"><abbr title="iPhone OS">iOS</abbr></a>, <a href="https://www.apple.com/macos">macOS</a>, @@ -243,18 +242,18 @@ the process by tailoring the generic instructions in the <code><abbr>tz</abbr> README</code> file and installing the latest data yourself. System-specific instructions for installing the latest <code><abbr>tz</abbr></code> data have also been published -for <a href="https://www.ibm.com/developerworks/aix/library/au-aix-olson-time-zone/index…"><abbr>AIX</abbr></a>, +for <a href="https://developer.ibm.com/articles/au-aix-olson-time-zone/"><abbr>AIX</abbr></a>, <a href="https://source.android.com/devices/tech/config/timezone-rules">Android</a>, <a -href="http://userguide.icu-project.org/datetime/timezone"><abbr +href="https://unicode-org.github.io/icu/userguide/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 href="https://www.ibm.com/support/pages/java-sdk-time-zone-update-utility"><abbr>IBM</abbr> JDK</a>, <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>, <a href="https://nodatime.org/userguide/tzdb">Noda Time</a>, and <a -href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html#usage">OpenJDK/Oracle JDK</a>. +href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">OpenJDK/Oracle JDK</a>. Sources for the <code><abbr>tz</abbr></code> database are <a href="https://en.wikipedia.org/wiki/UTF-8"><abbr @@ -488,11 +487,6 @@ many of which also support runtimes lacking the <samp>timeZone</samp> option. href="https://github.com/formatjs/date-time-format-timezone"><samp>Intl.DateTimeFormat</samp> timezone polyfill</a> is freely available under a <abbr>BSD</abbr>-style license.</li> -<li><a -href="https://github.com/kshetline/compact-time-zone-generator">CompactTimeZoneGenerator</a> -compiles time zone data into a compact form designed for -JavaScript. It is freely available under a combination of -the <abbr>MIT</abbr> license and the Apache License.</li> <li>The <a href="https://date-fns.org/">date-fns</a> library manipulates timezone-aware timestamps in browsers and in <a href="https://nodejs.org/en/">Node.js</a>. @@ -546,9 +540,9 @@ It is freely available under a <abbr>BSD</abbr>-style license.</li> Definitions for Python</a> compiles <code><abbr>tz</abbr></code> source into <a href="https://www.python.org">Python</a>. It is freely available under a <abbr>BSD</abbr>-style license. -In code that can assume Python 3.9 or later it is superseded by -<a href="#python-zoneinfo"><code>zoneinfo.ZoneInfo</code></a> -and the <a href="#pypi-tzdata"><code>tzdata</code> Python package</a>.</li> +In code that can assume Python 3.6 or later it is largely superseded; see <a +href="https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html">pytz: +The Fastest Footgun in the West</a>.</li> <li><a href="https://tzinfo.github.io">TZInfo – Ruby Timezone Library</a> compiles <code><abbr>tz</abbr></code> source into @@ -610,11 +604,11 @@ is a <abbr>TZif</abbr> file reader written in Perl. It is freely available under the same terms as Perl (dual <abbr>GPL</abbr> and Artistic license).</li> <li>Python has a <a id="python-zoneinfo" -href="https://docs.python.org/3.9/library/zoneinfo.html"><code>zoneinfo.ZoneInfo</code> +href="https://docs.python.org/3/library/zoneinfo.html"><code>zoneinfo.ZoneInfo</code> class</a> that reads <abbr>TZif</abbr> data and creates objects that represent <code><abbr>tzdb</abbr></code> timezones. Python is freely available under the -<a href="https://docs.python.org/3.9/license.html">Python Software Foundation +<a href="https://docs.python.org/3/license.html">Python Software Foundation License</a>. A companion <a id="pypi-tzdata" href="https://pypi.org/">PyPI</a> module <a href="https://pypi.org/project/tzdata/"><code>tzdata</code></a> @@ -641,7 +635,7 @@ available under a <abbr>BSD</abbr>-style license.</li> <li><a href="https://foxclocks.org">FoxClocks</a> is an extension for <a href="https://www.google.com/chrome/">Google Chrome</a> and for <a -href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Toolkit_API">Mozilla +href="https://wiki.mozilla.org/Modules/Toolkit">Mozilla Toolkit</a> applications like <a href="https://www.mozilla.org/en-US/firefox/new/">Firefox</a> and <a href="https://www.mozilla.org/en-US/thunderbird/">Thunderbird</a>. @@ -1010,14 +1004,11 @@ specifies a <a href="https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol"><abbr>DHCP</abbr></a> option for a server to configure a client's time zone and daylight saving settings automatically.</li> -<li><a -href="https://www.cv.nrao.edu/~rfisher/Ephemerides/times.html">Astronomical -Times</a> explains more abstruse astronomical time scales like +<li><a href="https://www.ucolick.org/~sla/leapsecs/timescales.html">Time +Scales</a> describes astronomical time scales like <abbr title="Terrestrial Dynamic Time">TDT</abbr>, <abbr title="Geocentric Coordinate Time">TCG</abbr>, and <abbr title="Barycentric Dynamic Time">TDB</abbr>. -<a href="https://www.ucolick.org/~sla/leapsecs/timescales.html">Time -Scales</a> goes into more detail, particularly for historical variants.</li> <li>The <a href="https://www.iau.org"><abbr title="International Astronomical Union">IAU</abbr></a>'s <a href="http://www.iausofa.org"><abbr -- 2.32.0

1 0

Just :)
by Sergiusz Wolicki March 11, 2022

March 11, 2022

Ryan Reynolds (@VancityReynolds) wysłał/a Tweeta o godz. 3:29 PM on pt., mar 11, 2022: As if making #TheAdamProject hadn’t satisfied enough of my childhood dreams, this happened. (I still loathe Daylight Savings.) https://t.co/9lAjYzjOnW ( https://twitter.com/VancityReynolds/status/1502290590242910208?t=zCwO45RshV… )

1 0

Re: [tz] Summer time
by heba.hamad＠mtit.gov.ps March 10, 2022

March 10, 2022

Dear sir, regarding to summer time for this year , the timing will be on 3/27/2022, but this does not necessarily mean that the change for the coming years will be on the same date. You will be provided with any new decisions about summer and winter times for the coming years and we will try to provide you with any changes more earlier than previous years. BR, في الخميس, مارس 10, 2022 14:26 EST, Paul Eggert <eggert(a)cs.ucla.edu> كتب: 3/04:50,http://www.palestinecabinet.gps/portal/Meeting/Details/51955 heba.hamad(a)mtit.gov.ps wrote: > We would like to inform you that the summer time will begin in Palestine from Sunday 03-27-2022 ,00:00 AM by 60 minutes forward. Thanks, do you have a URL for that announcement? It sounds like Palestine is changing its spring-forward rules, so that Palestine will now spring forward at 00:00 on the first Sunday on or after March 25, whereas during 2020 and 2021 Palestine sprang forward at 00:00 on the first Saturday after March 24. Is my understanding correct? Knowing the transition rule would be helpful, because TZDB makes predictions about future years, some computer applications rely on this (perhaps unwisely, but that's what they do), and the more accurate the predictions the better off everybody will be. This is related to Clive Feather's point that we need plenty of advance notice of rule changes (we'd like a year's notice). Without knowing the answers to the above questions, I installed the attached proposed patch into the TZDB development version. If possible, I'd like to improve this (based on answers to the above questions) before the next TZDB release, which should happen soon.

1 0

Summer time
by heba.hamad＠mtit.gov.ps March 10, 2022

March 10, 2022

Dear Sir, Greeting from Ministry of telecom and information technology, Palestine We would like to inform you that the summer time will begin in Palestine from Sunday 03-27-2022 ,00:00 AM by 60 minutes forward. Kindly find the attachment below that includes the decision of the Palestinian cabinet. BR

3 2

Jordan summer time zone is not updated in IANA database
by Abugharbieh, Raghad March 2, 2022

March 2, 2022

Hello I’m sure if you’re already aware of this or not , but in Jordan the timezone was changed on Thursday to meet summer changes. So currently , time zone in IANA database is behind the real time in Jordan by 1 hour . this is causing some time issues in websites that use IANA database. I’m sending this to check if there’s anything I can do to update the timezone for Jordan in the database to fix the root cause instead of handling the issues we have in a hacky way . Best regards , Raghad Abugharbieh

2 1

DST in mainstream media
by Arthur David Olson Feb. 28, 2022

Feb. 28, 2022

"Freezing the clock: Nationwide push for permanent daylight saving time gains momentum" Washington Post, 2022-02-28 (timeanddate.com gets a shoutout.) https://www.washingtonpost.com/dc-md-va/2022/02/28/permanent-daylight-savin… @dashdashado

1 0

backzone Africa/Lubumbashi
by Alois Treindl Feb. 28, 2022

Feb. 28, 2022

In file backzone there is an entry for Africa/Lubumbashi # Democratic Republic of the Congo (east) Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 2:00 - CAT There are scarce sources for time zones of former Belgian Congo. My main source for its time zone history is Henri le Corre, Régimes horaires pour l'Europe et l'Afrique. He has for the eastern provinces of Zaire GMT + 1 between 1897 Nov 9 GMT + 2 since 1920 Apr 25. Shanks follows le Corre. As does Francoise Schneider Gauquelin in he book Problèmes de l'heure resolus pout le monde entier. I think this is sufficient reason to change the zone into Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 1:00 - WAT 1920 Apr 25 2:00 - CAT For the province of Kisangani, formerly Stanleyville, le Corre gives a transition from GMT +1 to GMT + 2 on 1935 Jun 14. But as this agrees with Lubumbashi after 1970, I do not expect the creation of another backzone entry for that. This task will be left for my private pre-1970 TZ extensions.

2 1

(no subject)
by Dennis Dau Feb. 24, 2022

Feb. 24, 2022

Take Russia off the time zones for now sanctioned by the United States of America for starting war yesterday with our alias

1 0

Brisbane's lord mayor calls for referendum on Queensland DST
by Gilmore Davidson Feb. 22, 2022

Feb. 22, 2022

https://www.theguardian.com/australia-news/2022/feb/22/queensland-daylight-… Thirty years after Queenslanders rejected daylight saving at the polls, > Brisbane lord mayor, Adrian Schrinner, is calling for a new referendum on > the divisive subject. > > [...] Queenslanders voted against permanently introducing daylight saving > time after a three-year trial back in 1992. Schrinner says most people > under the age of 48 and anyone who moved to the state in the last 30 years > hasn’t had a say on adjusting time zones. > > [...] Schrinner suggested a new referendum could be held at the same time > as the next state election in 2024. > > [...] The attorney general, Shannon Fentiman, responded to an > anti-daylight saving time petition to parliament in December, saying [it] > was “not currently” under consideration. > Cheers, Gil

1 0

(no subject)
by 이상준 Feb. 22, 2022

Feb. 22, 2022

-- 이상준1978.06.28

1 0

proposed change to Europe/Kaliningrad in 1945
by Alois Treindl Feb. 21, 2022

Feb. 21, 2022

Currently the zone Europe/Kaliningrad has Zone Europe/Kaliningrad 1:22:00 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 Apr 10 2:00 Poland EE%sT 1946 Apr 7 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s 2:00 - EET I wonder on which source this line is based: 2:00 Poland EE%sT 1946 Apr 7 It implies these time changes: 29 April 1945 from 2:00 to 3:00 like Poland DST 1 November 1945 from 3:00 back to 2:00 Russia took control of Königsberg/Kaliningrad in East Prussia on 10 April 1045. As a general rule, Russia imposed timezone 2:00 on occupied German territory in 1945, which is the same as German DST already in force from 2 April 1945. On 24 May 1945 Russia imposed double DST, making the effective time 3:00 east, until 24 Sept 1945, when it went back to 2:00 and then back to 1:00 (CET) on 18 Nov 1945. Now what happened in Königsberg? The Potsdam agreement of 2 August 1945 : (quote from Wikipedia) > The Conference has agreed in principle to the proposal of the Soviet > Government concerning the ultimate transfer to the Soviet Union of the > City of Koenigsberg and the area adjacent to it as described above > subject to expert examination of the actual frontier. Russia annexed the area on 17 October 1945, and integrated into the republic of Russia on 7 April 1946. Poland had no role to play in this matter. Regarding time regime, I would assume that the transition from 2:00 to 1:00 of 18 Nov 1945, for occupied Germany, did not happen in Kaliningrad. It was already annexed. It remained at 2:00 until 7 April 1946, when it was integrated and went to Moscow time. This transition on 7 April 1946 is also found in Shanks. Shanks does not have the double DST from 24 May to 24 September 1945, but I think he is wrong there. Why should the Russians have treated East Prussia from the rest of the occupied German territory in May 1945. That would make the zone table like this ( I marked the difference in red) Zone Europe/Russia/Kaliningrad 1:22:00 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 Apr 10 1:00 1:00 CEST 1945 May 24 2:00 1:00 2:00 CEMT 1945 Sep 24 3:00 1:00 1:00 CEST 1945 Oct 17 2:00 - EET 1946 Apr 7 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s 2:00 - EET I have tried to simplify Zone Europe/Russia/Kaliningrad 1:22:00 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 Apr 10 1:00 SovietZone CE%sT 1945 Oct 17 2:00 - EET 1946 Apr 7 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s 2:00 - EET but get an error: can't determine time zone abbreviation to use just after until time at this line in tzdata.zi 1 So CE%sT 1945 O 17 This is why I made the changes implied by rule SovietZone explicit

2 2

Maryland permanent DST
by Arthur David Olson Feb. 21, 2022

Feb. 21, 2022

A permanent-DST bill has been approved by the Maryland House of Delegates on a third-and-final 108-24 vote; it now goes to the state senate. Text of the bill is available at... https://mgaleg.maryland.gov/2022RS/bills/hb/hb0126T.pdf …and status of the bill at... https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb0126 There are contigencies: (1) enacting of a similar act by Delaware, the District of Columbia, Pennsylvania, Virginia, and West Virginia; and (2) 15 U.S.C. § 260a being amended to allow the states or a state, individually, to observe a year–round standard time that is consistent with Eastern Daylight Time Alas, if the contingencies are met there may be short lead time before a change: Section 1 of this Act shall take effect on the earlier of the second Sunday of March or the first Sunday of November after the [contigencies have been met]… Alas further, the senate (unlike the house) has returned to in-person hearings; written communications can be sent. One suggestion I’ve thought of making is to change “the earlier of” to “the later of” for kick-in; that would buy at least a few guaranteed months of lead time. I’d welcome any better suggestions; I’d also welcome any Marylander with more political weight than I have (read: anyone) to weigh in. --ado

6 6

Issues about parts of Europe/Moscow in 1981/1982
by Alois Treindl Feb. 21, 2022

Feb. 21, 2022

I have the impression that some of the comments in the Russia section in file 'europe' have not been followed through in the actual zone tables. I refer to the lines beginning here # From Stepan Golosunov (2016-03-07): # 11. Regions-violators, 1981-1982. # Wikipedia refers to # http://maps.monetonos.ru/maps/raznoe/Old_Maps/Old_Maps/Articles/022/3_1981.… # http://besp.narod.ru/nauka_1981_3.htm ... until # 12. Udmurtia Also the Russian wikipedia page https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D1%81%D0%BA%D0%BE%D0%B2%D1%81%D0… contains the sentence (in Google translation) > In the autumn of 1981, Arkhangelsk, Vologda, Yaroslavl, Ivanovo, > Vladimir, Ryazan, Lipetsk, Voronezh, Rostov-on-Don, Krasnodar and > regions to the east of those named (about 30 in total) parted ways > with Moscow time.However, the convenience of common time with Moscow > turned out to be decisive - in 1982, these regions again switched to > Moscow time. Shanks International atlas has similar information, and also the Russian book Zaitsev A., Kutalev D. A new astrologer's reference book. Coordinates of cities and time corrections, - The World of Urania, 2012 Russian: Зайцев А., Куталёв Д., Новый справочник астролога. Координаты городов и временные поправки To me it seems that an extra zone is needed, which starts with LMT util 1919, later follows Moscow since 1930, but deviates from it between 1 October 1981 until 1 April 1982. I suggest to call this zone Europe/Yaroslavl, because Yaroslavl with a population of 608'000 seems to be largest city in the deviating area.

3 4

(no subject)
by Lanny Dorn Feb. 13, 2022

Feb. 13, 2022

seigepopcorn(a)gmail.com--

1 0

TZ data base and code
by Jin Quan Shen Feb. 3, 2022

Feb. 3, 2022

Hi, I have download and compiled timezone code and data base from https://opensource.apple.com/source/TimeZoneData/TimeZoneData-88/ tzcode2018e.tar.gz<https://opensource.apple.com/source/TimeZoneData/TimeZoneData-88/tzcode2018…> tzdata2018e.tar.gz<https://opensource.apple.com/source/TimeZoneData/TimeZoneData-88/tzdata2018…> Ran tzselect, zdump, zic however unable to execute successfully. What are causes and any suggestion? [cid:17778879-34f0-4bb4-99a5-6e7c0e5ff4ee] Regards, JinQuan Seagate Internal

2 4

[PROPOSED] Improve doc for some source files
by Paul Eggert Jan. 27, 2022

Jan. 27, 2022

* theory.html: Mention zone.tab and improve description of 'backward' and 'etcetera'. The goal of this change is to describe existing practice, and to allay concerns that names listed in 'backward' are going away. --- theory.html | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/theory.html b/theory.html index 5a05f4b..28cc88e 100644 --- a/theory.html +++ b/theory.html @@ -296,7 +296,7 @@ in decreasing order of importance: </li> <li> If a name is changed, put its old spelling in the - '<code>backward</code>' file. + '<code>backward</code>' file as a link to the new spelling. This means old spellings will continue to work. Ordinarily a name change should occur only in the rare case when a location's consensus English-language spelling changes; for example, @@ -348,22 +348,37 @@ timestamps correctly and it increased maintenance burden. </ul> -The file '<code>zone1970.tab</code>' lists geographical locations used +The file <code>zone1970.tab</code> lists geographical locations used to name timezones. It is intended to be an exhaustive list of names for geographic regions as described above; this is a subset of the timezones in the data. -Although a '<code>zone1970.tab</code>' location's +Although a <code>zone1970.tab</code> location's <a href="https://en.wikipedia.org/wiki/Longitude">longitude</a> corresponds to its <a href="https://en.wikipedia.org/wiki/Local_mean_time">local mean time (<abbr>LMT</abbr>)</a> offset with one hour for every 15° east longitude, this relationship is not exact. +The backward-compatibility file <code>zone.tab</code> is similar +but conforms to the older-version guidelines related to <abbr>ISO</abbr> 3166-1; +it lists only one country code per entry and unlike <code>zone1970.tab</code> +it can list names defined in <code>backward</code>. -Excluding '<code>backward</code>' should not affect the other data. -If '<code>backward</code>' is excluded, excluding -'<code>etcetera</code>' should not affect the remaining data. +The database defines each timezone name to be a zone, or a link to a zone. +The source file <code>backward</code> defines links for backward +compatibility; it does not define zones. +Although <code>backward</code> was originally designed to be optional, +nowadays distributions typically use it +and no great weight should be attached to whether a link +is defined in <code>backward</code> or in some other file. +The source file <code>etcetera</code> defines names that may be useful +on platforms that do not support POSIX-style <code>TZ</code> strings; +no other source file other than <code>backward</code> +contains links to its zones. +One of <code>etcetera</code>'s names is <code>GMT</code>, +used by functions like <code>gmtime</code> to obtain leap +second information on platforms that support leap seconds. </section> -- 2.32.0

2 1

[PATCH 1/2] I18nize zdump a bit better
by Paul Eggert Jan. 26, 2022

Jan. 26, 2022

* zdump.c (sumsize, show): Translate diagnostics that were mistakenly untranslated. --- zdump.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/zdump.c b/zdump.c index be8ac30..dc3dca8 100644 --- a/zdump.c +++ b/zdump.c @@ -146,7 +146,7 @@ sumsize(size_t a, size_t b) { size_t sum = a + b; if (sum < a) { - fprintf(stderr, "%s: size overflow\n", progname); + fprintf(stderr, _("%s: size overflow\n"), progname); exit(EXIT_FAILURE); } return sum; @@ -813,7 +813,7 @@ show(timezone_t tz, char *zone, time_t t, bool v) gmtmp = my_gmtime_r(&t, &gmtm); if (gmtmp == NULL) { printf(tformat(), t); - printf(" (gmtime failed)"); + printf(_(" (gmtime failed)")); } else { dumptime(gmtmp); printf(" UT"); @@ -823,7 +823,7 @@ show(timezone_t tz, char *zone, time_t t, bool v) tmp = my_localtime_rz(tz, &t, &tm); if (tmp == NULL) { printf(tformat(), t); - printf(" (localtime failed)"); + printf(_(" (localtime failed)")); } else { dumptime(tmp); if (*abbr(tmp) != '\0') -- 2.34.1

1 1

[PROPOSED] Simplify recent zdump port
by Paul Eggert Jan. 25, 2022

Jan. 25, 2022

* zdump.c (tformat): Simplify by using default promotions. --- zdump.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/zdump.c b/zdump.c index 79ff1fd..be8ac30 100644 --- a/zdump.c +++ b/zdump.c @@ -1148,12 +1148,8 @@ tformat(void) /* C11-style _Generic is more likely to return the correct format when distinct types have the same size. */ char const *fmt = - _Generic((time_t) 0, - signed char: "%d", short: "%d", int: "%d", - long: "%ld", long long: "%lld", - char: CHAR_MAX <= INT_MAX ? "%d" : "%u", - unsigned char: UCHAR_MAX <= INT_MAX ? "%d" : "%u", - unsigned short: USHRT_MAX <= INT_MAX ? "%d" : "%u", + _Generic(+ (time_t) 0, + int: "%d", long: "%ld", long long: "%lld", unsigned: "%u", unsigned long: "%lu", unsigned long long: "%llu", default: NULL); -- 2.34.1

1 0

[PATCH] zdump ports better to odd C11 platforms
by Paul Eggert Jan. 25, 2022

Jan. 25, 2022

* zdump.c (HAVE_GENERIC): Define if not already defined, with the same definiens as private.h. (tformat): Prefer _Generic if it works, as this is more reliable than guessing via sizeof. --- zdump.c | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/zdump.c b/zdump.c index f08afbd..79ff1fd 100644 --- a/zdump.c +++ b/zdump.c @@ -56,6 +56,21 @@ */ enum { SECSPER400YEARS_FITS = SECSPERLYEAR <= INTMAX_MAX / 400 }; +#if !defined HAVE_GENERIC && defined __has_extension +# if __has_extension(c_generic_selections) +# define HAVE_GENERIC 1 +# else +# define HAVE_GENERIC 0 +# endif +#endif +/* _Generic is buggy in pre-4.9 GCC. */ +#if !defined HAVE_GENERIC && defined __GNUC__ +# define HAVE_GENERIC (4 < __GNUC__ + (9 <= __GNUC_MINOR__)) +#endif +#ifndef HAVE_GENERIC +# define HAVE_GENERIC (201112 <= __STDC_VERSION__) +#endif + #if HAVE_GETTEXT #include <locale.h> /* for setlocale */ #endif /* HAVE_GETTEXT */ @@ -1123,12 +1138,33 @@ abbr(struct tm const *tmp) /* ** The code below can fail on certain theoretical systems; -** it works on all known real-world systems as of 2004-12-30. +** it works on all known real-world systems as of 2021-01-25. */ static const char * tformat(void) { +#if HAVE_GENERIC + /* C11-style _Generic is more likely to return the correct + format when distinct types have the same size. */ + char const *fmt = + _Generic((time_t) 0, + signed char: "%d", short: "%d", int: "%d", + long: "%ld", long long: "%lld", + char: CHAR_MAX <= INT_MAX ? "%d" : "%u", + unsigned char: UCHAR_MAX <= INT_MAX ? "%d" : "%u", + unsigned short: USHRT_MAX <= INT_MAX ? "%d" : "%u", + unsigned: "%u", unsigned long: "%lu", + unsigned long long: "%llu", + default: NULL); + if (fmt) + return fmt; + fmt = _Generic((time_t) 0, + intmax_t: "%"PRIdMAX, uintmax_t: "%"PRIuMAX, + default: NULL); + if (fmt) + return fmt; +#endif if (0 > (time_t) -1) { /* signed */ if (sizeof(time_t) == sizeof(intmax_t)) return "%"PRIdMAX; -- 2.34.1

1 0

Wrong zdump output in timezone-2021e
by Danilo Spinella Jan. 25, 2022

Jan. 25, 2022

Hi everyone! I have encountered a strange behaviour in zdump in the latest version of timezone (timezone-2021e). Previous output of version timezone-2021a: # zdump Europe/Copenhagen -v -c 2022,2023 | grep isdst Europe/Copenhagen Sun Mar 27 00:59:59 2022 UT = Sun Mar 27 01:59:59 2022 CET isdst=0 gmtoff=3600 Europe/Copenhagen Sun Mar 27 01:00:00 2022 UT = Sun Mar 27 03:00:00 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 00:59:59 2022 UT = Sun Oct 30 02:59:59 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 01:00:00 2022 UT = Sun Oct 30 02:00:00 2022 CET isdst=0 gmtoff=3600 Current output with timezone-2021e: # zdump Europe/Copenhagen -v -c 2022,2023 | grep isdst Europe/Copenhagen -67768040609743820 = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=3020 Europe/Copenhagen -67768040609740801 = Thu Jan 1 00:50:19 -2147481748 LMT isdst=0 gmtoff=3020 Europe/Copenhagen Thu Jan 1 00:00:00 -2147481748 UT = Thu Jan 1 00:50:20 -2147481748 LMT isdst=0 gmtoff=3020 Europe/Copenhagen Sun Mar 27 00:59:59 2022 UT = Sun Mar 27 01:59:59 2022 CET isdst=0 gmtoff=3600 Europe/Copenhagen Sun Mar 27 01:00:00 2022 UT = Sun Mar 27 03:00:00 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 00:59:59 2022 UT = Sun Oct 30 02:59:59 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 01:00:00 2022 UT = Sun Oct 30 02:00:00 2022 CET isdst=0 gmtoff=3600 Europe/Copenhagen Wed Dec 31 22:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 CET isdst=0 gmtoff=3600 I consider this a bug due to the strange values printed by zdump. I have tested zdump in different distributions and they are all affected. Can you please confirm? -- Best Regards, Danilo Spinella

2 1

Re: [tz] Unexpected footer in Africa/Casablanca
by Paul Eggert Jan. 25, 2022

Jan. 25, 2022

On 1/10/22 08:55, Almaz Mingaleev wrote: > I was investigating generated TZif files and the generated footer for > Africa/Casablanca is "XXX-2<+01>-1,0/0,J365/23". Is that expected? > Effectively it behaves like GMT+1, but SAVE is -1:00 even though it is > 1:00 in rearguard.zi. How do I instruct zic to generate plain "<+01>-1" > or skip it at all? One fix is to change ziguard.awk to generate a rearguard-format .zi file that has a more-natural transition for Morocco in May 2087. ("More- natural" from the rearguard viewpoint that is; it's more-awkward from a real-world viewpoint.) Proposed patch attached; it causes the string to be "<+01>-1" for rearguard format too. Thanks for reporting the glitch. > I believe I am doing something wrong, as in MacOs it is empty and > "<+01>-1" in Linux, but I can't figure out what command options I should > specify in zic. It's "<+01>-1" on GNU/Linux platforms like Ubuntu and Fedora that use the default format. These distros are not using rearguard-format TZif files and so don't have rearguard issues there. I'm not sure why it's empty in macOS. macOS 12.1's 'zic --version' reports "zic: @(#)zic.c 8.22" which corresponds to tzcode2010m, so perhaps it's merely because macOS is stuck on a tzcode version that is so old that you can't easily tell that macOS is using rearguard format. (macOS's zdump doesn't seem to work past the year 2038, and Apple should upgrade well before that year rolls around.) While we're on the subject, what is Android's current state of support for negative DST and for timestamps past 2038? On the GNU/Linux side, I expect most distros support both - the stragglers being old-fashioned 32-bit x86 and ARM distros, where 64-bit timestamps weren't supported until Linux 5.6 (2020-03-29) and glibc 2.34 (2021-08-02), and even now many apps haven't been updated yet.

2 3

The State of Palestine has adopted the first part of the specification for its time zone
by heba.hamad＠mtit.gov.ps Jan. 24, 2022

Jan. 24, 2022

Dear Sir, Hope this email finds you well and wishing you a joyful new year . We would like to inform you that The State of Palestine has adopted the first part of the specification for its time zone. Kindly refer to the attachment below, which includes the specification and please provide me with any comments or notes you have regarding this specification. Ps: Please provide me with any comments you have. Sincerely Yours, Eng.Heba Hamad MTIT -Palestine Sent from Mail for Windows

5 7

[YBA] TLD make using mawk causes malloc failure
by Jonathan Ben Avraham Jan. 19, 2022

Jan. 19, 2022

Dear colleagues, I noticed that on all tz versions up to 2021e running make in the top-level directory results in a malloc failure on Debian 10 which uses the mawk alternate for awk: cc -DTZDIR='"/usr/share/zoneinfo"' -c -o difftime.o difftime.c rm -f libtz.a ar -rc libtz.a localtime.o asctime.o difftime.o strftime.o : libtz.a awk -v DATAFORM=`expr main.zi : '\(.*\).zi'` -f ziguard.awk \ africa antarctica asia australasia europe northamerica southamerica etcetera factory backward >main.zi.out malloc(): unsorted double linked list corrupted Aborted make: *** [Makefile:612: main.zi] Error 134 This can be corrected by installing gawk and running update-alternatives --config awk to select gawk as the awk alternate. I verified that the make completes without error using either GNU Awk 4.1.4, or GNU Awk 4.2.1. I did not see any warning about this in any of the NEW or README files, which is unfortunate as I spent several hours of my employers time understanding the problem and I suspect that others have seen this already. I suggest adding an INSTALL readme to say which environments are known to work and if there are specific know issues such as mawk. Best regards, - yba -- 9590 8E58 D30D 1660 C349 673D B205 4FC4 B8F5 B7F9 ~. .~ Tk Open Systems =}-------- Jonathan Ben-Avraham ("yba") ----------ooO--U--Ooo------------{= mailto:yba@tkos.co.il tel:+972.52.486.3386 http://tkos.co.il skype:benavrhm

3 3

Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone
by Doug Ewell Jan. 15, 2022

Jan. 15, 2022

heba.hamad at mtit.gov.ps wrote: > We would like to inform you that The State of Palestine has adopted > the first part of the specification for its time zone. and linked a document which states in part: > Names normally have the form AREA/LOCATION, where AREA is a continent > or ocean, and LOCATION is a specific location within the area. > > The State of Palestine is the Palestine Time Zone owner, It has the > sole right to set, modify and register the Standard Time Zone; Name / > Database / DST. The Time Zone Database includes two zones related to Palestine, with the identifiers "Asia/Gaza" and "Asia/Hebron". These zones differ for (recent) historical reasons, because the rules for summer time (daylight saving time) varied during the period from 2008 to 2012. The file "asia" in the TZDB has comments which explain the exceptions for Gaza. By stating: > Palestine will use Palestine Standard Time (PSST), and Palestine > daylight time (PSDT). the PSI document appears to signal that the entire State of Palestine will observe a single changeover date and time, and will no longer observe different changeover dates in Gaza. However, for historical reasons involving the 2008–2012 daylight time discrepancies, both zones will continue to be reflected in TZDB. The TZDB administrators will retain the right to keep the identifiers "Asia/Gaza" and "Asia/Hebron", or to change them according to rules that they and the larger community have established. Governments or other bodies do not determine these identifiers, and cannot unilaterally claim the right to do so. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

1 0

No leap second on 2022-06-30
by Tim Parenti Jan. 11, 2022

Jan. 11, 2022

Per IERS, Bulletin C 63 (2022-01-05) https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.63 …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: Wed, 5 Jan 2022 at 10:43 Subject: Bulletin C number 63 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, 05 January 2022 Bulletin C 63 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 2022. 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