- tz - lists.iana.org

[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

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

Jan. 5, 2022

On 1/4/22 09:12, Eliot Lear via tz wrote: > The TZ update process here has no formal recognition of governments (any governments). Still, statements from governments, however they reach this group, tend to carry a lot of weight. Quite true. In the past we've given a lot of weight to official government documents, and we welcome future cooperation in this area as this will streamline communication. (All too often for many countries in the past, we've had to rely on third parties or the popular press to forward their governments' information to us, which has resulted in inaccuracies and delays in updating the database.) From the timekeeping point of view, the most important thing is to know the UTC offsets and the rules for when daylight saving time starts and stops in Palestine, and for technical reasons it's best to have this nailed down well in advance - preferably at least a year before rules change. Currently for Palestine, tzdb lists standard time of UTC+02, and it says daylight saving time starts at 00:00 on the first Saturday on or after March 24, and ends at 01:00 on the first Friday on or after October 23. Unfortunately, as far as I know these daylight saving time rules are not official, in that there's no official Palestinian government document listing these rules for future years; however, tzdb must put *something* in the database and that's the best guess we've come up with. If the government could publish an official document stating what the rules are for future years, we'd be happy to adjust tzdb to match that. Of lesser importance is the English-language abbreviation used for standard and daylight saving time in Palestine. (This is less important because most timekeeping applications do not rely on these abbreviations, as they are inherently ambiguous and somewhat deprecated anyway.) Here, tzdb attempts to follow common practice, and it currently uses the same longstanding abbreviations for time in Palestine that it uses for Cyprus, Egypt, Jordan, Lebanon, and Syria - namely "EET" and "EEDT" (short for "Eastern European Time" and "Eastern European Summer Time"). I am unaware of any English-language use of the abbreviations "PSST" and "PSDT" to refer to civil timekeeping in this area. However, if these abbreviations become popular in common practice we should change tzdb to incorporate them.

2 2

Re: [tz] The State of Palestine has adopted the first part of thespecification for its time zone
by Sanjeev Gupta Jan. 4, 2022

Jan. 4, 2022

On Tue, Jan 4, 2022 at 7:24 PM <heba.hamad(a)mtit.gov.ps> wrote: > What is meant in general is that the State of Palestine (the Palestinian > government) is the only authorized one to address the international > bodies, including IANA, to request any amendment, update, registration, > or anything else related to the subject, > That may be hard to enforce. I am in Singapore, so what happens if I write to this list with information on the time in Hebron, or whether Gaza and Ramallah have the same DST date or not? I would be unauthorised to address IANA and request an update. or to publish any official decisions regarding the time Zone of the State > of Palestine. > Of course. That is unobjectionable. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane

2 1