November 2022 - tz - lists.iana.org

(no subject)
by Cool Gab19 Nov. 7, 2024

Nov. 7, 2024

can you add Philippine Daylight Time on your Database I think it was missing from the list of the time zones please reply immediately if solved thanks...

4 8

Buggy %z behaviour in strftime
by Almaz Mingaleev May 16, 2023

May 16, 2023

Attached code prints "+0000 America/Los_Angeles" both with glibc and with linked ToT strftime implementation. On MacOs it prints "-0800 America/Los_Angeles". Is it a known issue?

10 19

Re: [tz] Morocco : Ramdan Time Change 2021
by Paul Eggert March 15, 2023

March 15, 2023

On 3/19/21 3:15 AM, Semlali Naoufal wrote: > At the moment, we have no official government announcement to this effect. But, logically, the change to the GMT schedule should be made on the night of April 10-11, 2021 (last weekend before Ramadan). Yes, that's been the tzdb prediction too, ever since tzdb version 2018h (2018-12-23). For the record, here are tzdb's current predictions Morocco transitions during the next five years. Sun Apr 11 01:59:59 2021 UT = Sun Apr 11 02:59:59 2021 +01 Sun Apr 11 02:00:00 2021 UT = Sun Apr 11 02:00:00 2021 +00 Sun May 16 01:59:59 2021 UT = Sun May 16 01:59:59 2021 +00 Sun May 16 02:00:00 2021 UT = Sun May 16 03:00:00 2021 +01 Sun Mar 27 01:59:59 2022 UT = Sun Mar 27 02:59:59 2022 +01 Sun Mar 27 02:00:00 2022 UT = Sun Mar 27 02:00:00 2022 +00 Sun May 8 01:59:59 2022 UT = Sun May 8 01:59:59 2022 +00 Sun May 8 02:00:00 2022 UT = Sun May 8 03:00:00 2022 +01 Sun Mar 19 01:59:59 2023 UT = Sun Mar 19 02:59:59 2023 +01 Sun Mar 19 02:00:00 2023 UT = Sun Mar 19 02:00:00 2023 +00 Sun Apr 30 01:59:59 2023 UT = Sun Apr 30 01:59:59 2023 +00 Sun Apr 30 02:00:00 2023 UT = Sun Apr 30 03:00:00 2023 +01 Sun Mar 10 01:59:59 2024 UT = Sun Mar 10 02:59:59 2024 +01 Sun Mar 10 02:00:00 2024 UT = Sun Mar 10 02:00:00 2024 +00 Sun Apr 14 01:59:59 2024 UT = Sun Apr 14 01:59:59 2024 +00 Sun Apr 14 02:00:00 2024 UT = Sun Apr 14 03:00:00 2024 +01 Sun Feb 23 01:59:59 2025 UT = Sun Feb 23 02:59:59 2025 +01 Sun Feb 23 02:00:00 2025 UT = Sun Feb 23 02:00:00 2025 +00 Sun Apr 6 01:59:59 2025 UT = Sun Apr 6 01:59:59 2025 +00 Sun Apr 6 02:00:00 2025 UT = Sun Apr 6 03:00:00 2025 +01 Sun Feb 15 01:59:59 2026 UT = Sun Feb 15 02:59:59 2026 +01 Sun Feb 15 02:00:00 2026 UT = Sun Feb 15 02:00:00 2026 +00 Sun Mar 22 01:59:59 2026 UT = Sun Mar 22 01:59:59 2026 +00 Sun Mar 22 02:00:00 2026 UT = Sun Mar 22 03:00:00 2026 +01 Sun Feb 7 01:59:59 2027 UT = Sun Feb 7 02:59:59 2027 +01 Sun Feb 7 02:00:00 2027 UT = Sun Feb 7 02:00:00 2027 +00 Sun Mar 14 01:59:59 2027 UT = Sun Mar 14 01:59:59 2027 +00 Sun Mar 14 02:00:00 2027 UT = Sun Mar 14 03:00:00 2027 +01 Sun Jan 23 01:59:59 2028 UT = Sun Jan 23 02:59:59 2028 +01 Sun Jan 23 02:00:00 2028 UT = Sun Jan 23 02:00:00 2028 +00 Sun Mar 5 01:59:59 2028 UT = Sun Mar 5 01:59:59 2028 +00 Sun Mar 5 02:00:00 2028 UT = Sun Mar 5 03:00:00 2028 +01 Sun Jan 14 01:59:59 2029 UT = Sun Jan 14 02:59:59 2029 +01 Sun Jan 14 02:00:00 2029 UT = Sun Jan 14 02:00:00 2029 +00 Sun Feb 18 01:59:59 2029 UT = Sun Feb 18 01:59:59 2029 +00 Sun Feb 18 02:00:00 2029 UT = Sun Feb 18 03:00:00 2029 +01 Sun Dec 30 01:59:59 2029 UT = Sun Dec 30 02:59:59 2029 +01 Sun Dec 30 02:00:00 2029 UT = Sun Dec 30 02:00:00 2029 +00 Sun Feb 10 01:59:59 2030 UT = Sun Feb 10 01:59:59 2030 +00 Sun Feb 10 02:00:00 2030 UT = Sun Feb 10 03:00:00 2030 +01 Sun Dec 22 01:59:59 2030 UT = Sun Dec 22 02:59:59 2030 +01 Sun Dec 22 02:00:00 2030 UT = Sun Dec 22 02:00:00 2030 +00

3 9

Paraguay on its way to stay on DST
by Carlos Raúl Perasso March 2, 2023

March 2, 2023

On September 28, the Paraguayan Chamber of Deputies approved a bill that eliminates winter time in Paraguay. This would make Paraguay stay in DST throughout the year. The project was sent to the Senate for approval. After this, it could still have the presidential veto. If successful, the law would take effect after this weekend's time change, so the new rule should read as follows: Rule Para 2010 2022 - Oct Sun>=1 0:00 1:00 - Rule Para 2013 2022 - Mar Sun>=22 0:00 0 - I will keep you informed of the progress of the bill. Saludos, Carlos

2 2

[PATCH v2 1/4] zic.8: Add public domain notice
by Alejandro Colomar Dec. 13, 2022

Dec. 13, 2022

Signed-off-by: Alejandro Colomar <alx(a)kernel.org> --- Hi Paul, v2: - This time I sent them to the tz mailing list too (and also linux-man@). - Added ACK and review from Branden in 3/4 and 4/4. - Added comment from Branden to commit message in 4/4. - Added tweak suggested by Branden in 3/4. zic.8 | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/zic.8 b/zic.8 index f79148f4..c2c61739 100644 --- a/zic.8 +++ b/zic.8 @@ -1,3 +1,7 @@ +.\" %%%LICENSE_START(PUBLIC_DOMAIN) +.\" This page is in the public domain +.\" %%%LICENSE_END +.\" .TH ZIC 8 .SH NAME zic \- timezone compiler -- 2.38.1

3 18

1981/2 Singapore+Malaysia switch from GMT+0730 to GMT+0800
by Robert Elz Dec. 1, 2022

Dec. 1, 2022

This press release was discovered, and brought up in another forum by Geoff Clare. It conflicts with the data in the Asia/Singapore and Asia/Kuala-Lumpur zones. https://corporate.nas.gov.sg/media/collections-and-research/time-zone-adjus… That puts the change as being from 23:29:59 Dec 31, 1981 -> 00:00:00 Jan 1, 1982 whereas tzdata (going back to quite ancient versions) has the transition 23:59:59 Dec 31, 1981 -> 00:30:00 Jan 1, 1982 The version from the web page makes more sense to me (as in that is how I would have done that transition) but that does not mean that it is necessarily correct. Nothing there shows a copy of the actual gazette notification by the President (of Singapore in that case, but I think we can safely assume that it was done the same as in Malaysia) which would be the actual specification, but that 2015 press release says it happened as described that it would happen in the 1981 press release which is included there. The "asia" file just says of this transition: 7:30 - +0730 1982 Jan 1 8:00 - +08 which is correct in a sense for either version of when the transition occurred, and perhaps raises a general question of when a step forward takes place at the boundary between two days, does it more often delete the last part of the previous day or the first part of the next? I can find nothing in my tz list archives that says anything at all about this transition - the earliest message with any specific content about Singapore I could see was a Jan 2004 message from Mok Ly Yng (forwarded to the list by ado@), but that's really about earlier transitions - this one was already in the data (just with SGT instead of +0730 and +08). There's also a long Sept 2014 discussion about a zdump bug that this particular transition, as defined by zic, revealed, and a shorter discussion about the SGT removal in Sept 2018 - but that's all I managed to find about Singapore. While not about the Singapore/Malaysia zones themselves, even older data that appears on the list (ie: looking at diffs patches, and updated zone files) shows that in 1996 this transition was believed to have happened in May 1982 (which seems to be from Shanks). That altered in Dec 2003, in a change described as: * Fix several Malaysia and Singapore entries before 1983. Among other things, they enjoyed 20-minute DST from 1933 to 1936, and we have more-accurate dates for WWII transitions. (Thanks to Mok Ly Yng for this info.) which notably does not mention the change moving from May 1982 -> 1 Jan 1982 but that change was made in that version. Nothing appears to have happened since. I suspect it would be correct to change the first of those lines to be 7:30 - +0730 23:30 1981 Dec 30 but I am no authority on that. kre

5 13

Re: [tz] New change in Mexico
by Brian Inglis Nov. 30, 2022

Nov. 30, 2022

On 2022-11-29 22:37, Tim Parenti wrote: > On Tue, 29 Nov 2022 at 13:29, Paul Eggert wrote: > I expect I didn't recognize > that as including Ciudad Juárez as opposed to one of the plain Juárezes > which also exist in Mexico. > On Tue, 29 Nov 2022 at 19:50, Heitor David Pinto wrote: > The municipalities have well-defined boundaries, see this map: > https://cuentame.inegi.org.mx/mapas/pdf/entidades/div_municipal/chihmpios.p… > Ah, that seems to be part of the issue — while the word "municipality" is often > used to refer to an individual settlement in US English, a "municipio" in Mexico > (and similar words in many other countries) is a second-level administrative > division, which is more akin to, say, a county in much of the US or a civil > parish in much of Britain. That is, these lists are not of individual > settlements which are far apart (although they often share names with such), but > rather of well-defined regions — administrative subdivisions of states — which, > as Heitor points out, cover the entire border. > https://en.wikipedia.org/wiki/Municipio <https://en.wikipedia.org/wiki/Municipio> > https://en.wikipedia.org/wiki/Municipalities_of_Mexico > <https://en.wikipedia.org/wiki/Municipalities_of_Mexico> > While "municipio" does, admittedly, seem to be best translated to English as > "municipality", since the English word has many meanings, it's maybe best to be > more faithful to the original Spanish use here for clarity. We've left > "municipio" untranslated in nearby commentary for Mexico before, so I've applied > the attached to the development repository to hopefully alleviate some further > confusion for others who might come to these comments unaware of some of the > details of Mexico's political subdivisions. While I don't necessarily expect > many more one-off adjustments to the new arrangement in the immediate future, if > that does come to pass, it might behoove us to further standardize our > commentary for the various Mexican zones (in a similar manner as was done for > the many Russian zones in 2014). > Anyway, that puts the dividing line between the two resultant zones along the > border between the municipio of Guadalupe to the northwest and the municipios of > Coyame del Sotol and Ojinaga to the southeast …which meets the US border between > Barrio Alto and Presidio de Pilares, about 15 km south-southeast of my > (comparatively uninformed) guess, which I suppose wasn't all too bad for a > ~900-km-long border. Same in most European countries and Canadian provinces: https://en.wikipedia.org/wiki/Local_government_in_Canada#Regional_municipal… "Depending on the province, this second tier may be called a county, regional municipality, regional district or regional county municipality." There are also some district, island, mountain resort, resort, rural, and specialized municipalities, each of which may have varying geographic extents as an administrative chunk of a province. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

[PROPOSED 1/4] Always define STD_INSPIRED
by Paul Eggert Nov. 30, 2022

Nov. 30, 2022

* private.h (STD_INSPIRED): Default to 0. All uses changed. This is purely refactoring, so that STD_INSPIRED is more like other macros in this file. --- Makefile | 2 +- localtime.c | 10 +++++----- private.h | 7 +++++-- theory.html | 2 +- 4 files changed, 12 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 2c09f94..f0cbf7f 100644 --- a/Makefile +++ b/Makefile @@ -363,7 +363,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # -DNETBSD_INSPIRED=0 # to the end of the "CFLAGS=" line. Otherwise, the functions # "localtime_rz", "mktime_z", "tzalloc", and "tzfree" are added to the -# time library, and if STD_INSPIRED is also defined the functions +# time library, and if STD_INSPIRED is also defined to nonzero the functions # "posix2time_z" and "time2posix_z" are added as well. # The functions ending in "_z" (or "_rz") are like their unsuffixed # (or suffixed-by-"_r") counterparts, except with an extra first diff --git a/localtime.c b/localtime.c index 1d22d35..462d054 100644 --- a/localtime.c +++ b/localtime.c @@ -1697,7 +1697,7 @@ gmtime(const time_t *timep) return gmtime_r(timep, &tm); } -#ifdef STD_INSPIRED +#if STD_INSPIRED struct tm * offtime(const time_t *timep, long offset) @@ -1706,7 +1706,7 @@ offtime(const time_t *timep, long offset) return gmtsub(gmtptr, timep, offset, &tm); } -#endif /* defined STD_INSPIRED */ +#endif /* ** Return the number of leap years through the end of the given year @@ -2325,7 +2325,7 @@ mktime(struct tm *tmp) return t; } -#ifdef STD_INSPIRED +#if STD_INSPIRED time_t timelocal(struct tm *tmp) { @@ -2377,7 +2377,7 @@ leapcorr(struct state const *sp, time_t t) ** XXX--is the below the right way to conditionalize?? */ -#ifdef STD_INSPIRED +#if STD_INSPIRED /* NETBSD_INSPIRED_EXTERN functions are exported to callers if NETBSD_INSPIRED is defined, and are private otherwise. */ @@ -2462,7 +2462,7 @@ posix2time(time_t t) return t; } -#endif /* defined STD_INSPIRED */ +#endif /* STD_INSPIRED */ #if TZ_TIME_T diff --git a/private.h b/private.h index 9cb9c24..b5fdf5a 100644 --- a/private.h +++ b/private.h @@ -691,7 +691,10 @@ extern long altzone; ** declarations if time_tz is defined. */ -#ifdef STD_INSPIRED +#ifndef STD_INSPIRED +# define STD_INSPIRED 0 +#endif +#if STD_INSPIRED # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif @@ -738,7 +741,7 @@ struct tm *localtime_rz(timezone_t restrict, time_t const *restrict, time_t mktime_z(timezone_t restrict, struct tm *restrict); timezone_t tzalloc(char const *); void tzfree(timezone_t); -# ifdef STD_INSPIRED +# if STD_INSPIRED # if TZ_TIME_T || !defined posix2time_z time_t posix2time_z(timezone_t, time_t) ATTRIBUTE_REPRODUCIBLE; # endif diff --git a/theory.html b/theory.html index 75e347f..f2b798b 100644 --- a/theory.html +++ b/theory.html @@ -1173,7 +1173,7 @@ The vestigial <abbr>API</abbr>s are: </li> <li> The functions that are conditionally compiled - if <code>STD_INSPIRED</code> is defined should, at this point, be + if <code>STD_INSPIRED</code> is nonzero should, at this point, be looked on primarily as food for thought. They are not in any sense "standard compatible" – some are not, in fact, specified in <em>any</em> standard. -- 2.38.1

1 3

New change in Mexico
by Heitor David Pinto Nov. 29, 2022

Nov. 29, 2022

Hello, Mexico is planning to change time zones again. Last month, the whole state of Chihuahua moved to UTC-6 without DST, causing a time change across the border with the US for part of the year. Now the northern municipalities want to have the same time zone as the respective neighboring cities in the US, for example Juárez in UTC-7 with DST, matching El Paso, and Ojinaga in UTC-6 with DST, matching Presidio. The congress of Chihuahua and the federal Chamber and Senate all approved the change, following the combined procedure specified in the new time zone law, and now it awaits the president's approval. The change should occur on the day after the official publication of the law, again on short notice.https://politica.expansion.mx/congreso/2022/11/24/aprueban-que-ayuntamientos-fronterizos-de-chihuahua-tengan-horario-de-verano But there is another problem. The actual law that was passed says that Juárez and Ojinaga will observe UTC-7 and UTC-6 during the DST period, not outside of it. I think that this was an oversight as a result of trying to pass the law through all the chambers very quickly, but I can't believe that no one noticed it. There is a legislative procedure in Mexico called "fe de erratas" to correct obvious mistakes without having to pass the law again, but in this case the correction would have to alter multiple sections so I'm not sure if it will be possible. Either way, I expect confusion in the next days.http://gaceta.diputados.gob.mx/PDF/65/2022/nov/20221124-VII.pdf Regards,Dave

5 12

Re: [tz] [PROPOSED 2/5] Pacify gcc -std=c89 -pedantic with new attributes
by Brian Inglis Nov. 29, 2022

Nov. 29, 2022

On 2022-11-28 12:47, Paul Eggert via tz wrote: > On 2022-11-28 05:40, Philip Newton wrote: >> "have has" is a bit ugly.... > > Yes, I originally used the name "HAVE___HAS_C_ATTRIBUTE", since it tests whether > __has_c_attribute exists and that's the naming convention, but I changed it to > HAVE_HAS_C_ATTRIBUTE as I worried that the three adjacent underscores would be > confusing. If people prefer HAVE___HAS_C_ATTRIBUTE we can easily change to that. > The longer name would be more consistent. "4.2.8 __has_c_attribute The special operator __has_c_attribute (operand) may be used in ‘#if’ and ‘#elif’ expressions in C code to test whether the attribute referenced by its operand is recognized by GCC in attributes using the ‘[[]]’ syntax." How about HAVE_C23_ATTRIBUTE_CHECK, HAVE_C2X_ATTRIBUTE_CHECK, or something similarly more meaningful and less confusing? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

2 1