- tz - lists.iana.org

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> <p> -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>. </p> <p> -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. </p> </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