- tz - lists.iana.org

Re: [tz] Country name change from Turkey to Turkiye
by Brian Inglis Nov. 19, 2022

Nov. 19, 2022

On 2022-11-17 23:09, Bin Li via tz wrote: > Do you have any plans to change Turkey's name? Because it's the official name now. > https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-… <https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-…> One of the stupider ISO decisions, as English supports no accents, except in loanwords, and they are just ignored, except possibly in academic publishing. I think it is time native English language speakers push back against and ignore decisions made by international committees of non-native English language speakers, to try and change what native English language speakers use to what the foreign language uses in Latin alphabet transliterations, just as the other 100+ countries who have no "official" transliteration do. -- 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

3 2

Country name change from Turkey to Turkiye
by Bin Li Nov. 18, 2022

Nov. 18, 2022

Dear, Do you have any plans to change Turkey's name? Because it's the official name now. https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-…

6 8

New York Times: Time is Running Out for the Leap Second
by Jonathan Leffler Nov. 15, 2022

Nov. 15, 2022

https://www.nytimes.com/2022/11/14/science/time-leap-second.html -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

United States Senate reintroduced Sunshine Protection Act, enabling Permanent DST
by Phake Nick Nov. 14, 2022

Nov. 14, 2022

I don't quite understand the legal text of the bill itself [2], but according to my reading, it seems like the bill will end DST across the entire US by shifting the standard time forward an hour, except in states/territories/area that currently doesn't enact DST, which they can choose to follow the new standard time or old standard time? 1: https://www.rubio.senate.gov/public/index.cfm/2021/3/rubio-colleagues-reint… 2: https://www.rubio.senate.gov/public/_cache/files/d34c77c0-acea-4074-bc57-14…

18 26

[PATCH] use official source for 1993 end of time shift
by Alois Treindl Nov. 12, 2022

Nov. 12, 2022

--- southamerica | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/southamerica b/southamerica index 13cc65e..8eb5e25 100644 --- a/southamerica +++ b/southamerica @@ -1417,10 +1417,13 @@ Zone Antarctica/Palmer 0 - -00 1965 # Milne gives 4:56:16.4 for Bogotá time in 1899. He writes, # "A variation of fifteen minutes in the public clocks of Bogota is not rare." +# Alois Treindl quoted DECRETO 267 DE 1993 +# https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/1061335 +# Artículo 2° El cambio de hora se hará efectivo a las veinticuatro horas del día 6 de febrero del presente año. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - -Rule CO 1993 only - Apr 4 0:00 0 - +Rule CO 1993 only - Feb 7 0:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] #STDOFF -4:56:16.4 Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 -- 1.8.3.1

2 1

Re: [tz] Minor (unimportant really) technical UB bug in strftime() ?
by Brian Inglis Nov. 12, 2022

Nov. 12, 2022

On 2022-11-11 13:53, Paul Eggert via tz wrote: > On 2022-11-10 16:11, Tom Lane wrote: > >> simple modifications of the >> strftime() case can provide pretty good examples. > I'm not sure I'm following this argument, but if I understand it correctly I > disagree. I very much much want implementations to reject attempts to use > uninitialized data, and I don't want the C standard to prohibit such > implementations. Use of uninitialized data is a serious problem in real > applications - several CVEs have arisen from it - and the C standard shouldn't > require implementations to sweep it under the rug. > This call is obviously buggy since it is passing an uninitialized struct tm to > strftime. However, the C standard says the patched strftime's memcpy initializes > strftime's local variable tm, and therefore mktime's use of tm's contents is > defined and the implementation allow the program's use of uninitialized data. > > Whatever the reason for this peculiarity of the C standard (and nobody seems to > remember why it's there), it's counterproductive. In general C programs > shouldn't use uninitialized data. If they do, it's useful to have a debugging > implementation that reports any such use the instant that it happens as this > will help catch real bugs. And since common debugging implementations like > valgrind and UBSan are not following the C standard here, this suggests that the > C standard is mistaken, not the implementations. >> That leads either to strftime() knowing >> much more about mktime()'s innards than it ought to > It's not a problem for strftime, since strftime's has to know what's needed in > the struct tm; this follows from strftime's API. It may not know everything about the object, as there may be implementatiion extensions to deal with e.g. localization issues, and can never know everything about another function implementation, which could be changed at any time. > It might be a problem for other scenarios, such as the one you vaguely suggested > though I don't know the details. However, even assuming these other scenarios > exist, they don't justify this peculiarity of the C standard. The standard > should not say that the ordinary meaning of "don't use uninitialized variables" > is wrong and that there's some trickier interpretation that hardly any > programmer knows and that was wrong even in C17 and so needed rewording (and > perhaps still needs rewording) and that nevertheless must be supported - even > though important debugging implementations disagree. I think the principle is just to program carefully and generically around possible issues, when dealing with an opaque object you do not define and control, to avoid creating issues with private fields or functions which may be part of the implementation, but not in whatever documented interface you are programming to. Not all the world is...C, POSIX, or Linux, compliant. -- 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

Minor (unimportant really) technical UB bug in strftime() ?
by Robert Elz Nov. 11, 2022

Nov. 11, 2022

The code for the %s strftime conversion starts as: (this taken from tzcode2022f strftime.c - but I suspect that many versions are the same) case 's': { struct tm tm; char buf[INT_STRLEN_MAXIMUM( time_t) + 1]; time_t mkt; tm = *t; mkt = mktime(&tm); The "tm = *t;" line is the problem. It (or more correctly, something to replace that) is needed, as *t is const, strftime() is not permitted to modify it, yet the struct tm * passed to mktime() is not const, as mktime is sometimes required to modify that struct before returning. However, mktime() refers only to the fields tm_year tm_mon tm_mday tm_hour tm_min tm_sec and tm_isdst of the struct passed to it. The %s conversion is defined as producing (in a decimal string format) the result of mktime() applied to the struct tm passed to strftime. Hence an application which intends to use strftime(..., "%s", ...) need only initialise those 7 fields, the other 2 (currently) standard fields (tm_yday and tm_wday) are explicitly ignored by mktime() on input, so there is no need to assign those values, and any other fields that might exist in a particular implementation are out of scope for a portable (conforming) application to touch, so cannot be initialised. Since referring to an uninitialised variable is, I believe, technically undefined behaviour, doing a struct copy (copying all fields) can have that effect. (An application could memset() the entire struct before providing the values it must add, but is not required to do that). It seems likely that the simple fix is to replace the struct assignment with 7 individual assignment statements tm.tm_year = t->tm_year; tm.tm_mon = t->tm_mon; /* ... */ On the other hand, hardware that balks at simply loading or copying, uninitialised values, without using them for any purpose is not exactly common (and half the world's code would probably break if an implementation that worked in such a manner was ever created) so I'd call this one of the less significant issues to worry about fixing. kre

10 26

End of time change in Colombia 1993
by Alois Treindl Nov. 10, 2022

Nov. 10, 2022

TZ has for Colombia a single period with time zone 4h west. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - Rule CO 1993 only - Apr 4 0:00 0 - I think the end date 4 April is wrong, it should be 6 February 24h or 7 February 0h The time shift was called Hora Gaviria, and caused by shortage of electricity in connection with El Niño . Source: *DECRETO 267 DE 1993 * https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/1061335 *Artículo 1° *Adoptar como hora legal en el territorio de la República, la del Tiempo Universal Coordinado, UTC, disminuido en cinco (5) horas. *Artículo 2° *El cambio de hora se hará efectivo a las veinticuatro horas del día 6 de febrero del presente año. There is also a newspaper article https://www.eltiempo.com/archivo/documento/MAM-32922 of 4 feb 1993, but the text is less clear to my limited understanding of Spanish. See also https://es.wikipedia.org/wiki/Crisis_energ%C3%A9tica_de_1992_en_Colombia **

1 1

[PROPOSED] Support timegm by default, as per C23
by Paul Eggert Nov. 10, 2022

Nov. 10, 2022

Also, fix a bug in timegm; it sometimes modified its input even on failure. * Makefile, NEWS: Mention this. * localtime.c (mktmcpy): New static function. (time2sub): Use it. (timegm, timeoff): Define even if !STD_INSPIRED. (timeoff): Make it static if !STD_INSPIRED. (timegm): Do not modify *TMP on failure, even if only to change TMP->is_isdst. * private.h (HAVE_DECL_TIMEGM): Specify reasonable default value. (timegm): Always declare one way or another. --- Makefile | 8 +++----- NEWS | 5 +++++ localtime.c | 53 +++++++++++++++++++++++++++++++++-------------------- private.h | 18 +++++++++++++++--- 4 files changed, 56 insertions(+), 28 deletions(-) diff --git a/Makefile b/Makefile index 9ee15607..5ec0d4ab 100644 --- a/Makefile +++ b/Makefile @@ -209,6 +209,7 @@ LDLIBS= # For example, N is 252460800 on AmigaOS. # -DHAVE_DECL_ASCTIME_R=0 if <time.h> does not declare asctime_r # -DHAVE_DECL_ENVIRON if <unistd.h> declares 'environ' +# -DHAVE_DECL_TIMEGM=0 if <time.h> does not declare timegm # -DHAVE_DIRECT_H if mkdir needs <direct.h> (MS-Windows) # -DHAVE_GENERIC=0 if _Generic does not work* # -DHAVE_GETRANDOM if getrandom works (e.g., GNU/Linux), @@ -344,14 +345,11 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # If you want functions that were inspired by early versions of X3J11's work, # add # -DSTD_INSPIRED -# to the end of the "CFLAGS=" line. This arranges for the functions -# "offtime", "timelocal", "timegm", "timeoff", -# "posix2time", and "time2posix" to be added to the time conversion library. +# to the end of the "CFLAGS=" line. This arranges for the following +# functions to be added to the time conversion library. # "offtime" is like "gmtime" except that it accepts a second (long) argument # that gives an offset to add to the time_t when converting it. # "timelocal" is equivalent to "mktime". -# "timegm" is like "timelocal" except that it turns a struct tm into -# a time_t using UT (rather than local time as "timelocal" does). # "timeoff" is like "timegm" except that it accepts a second (long) argument # that gives an offset to use when converting to a time_t. # "posix2time" and "time2posix" are described in an included manual page. diff --git a/NEWS b/NEWS index 4a053077..23f1f7f1 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,7 @@ News for the tz database Briefly: Fix some pre-1996 timestamps in northern Canada + C23 timegm now supported by default Unreleased, experimental changes @@ -22,6 +23,10 @@ Unreleased, experimental changes Changes to code + timegm, which tzcode implemented in 1989, will finally be + standardized 34 years later as part of C23, so timegm is now + supported even if STD_INSPIRED is not defined. + Fix bug in zdump's tzalloc emulation on hosts that lack tm_zone. (Problem reported by Đoàn Trần Công Danh.) diff --git a/localtime.c b/localtime.c index 712be135..9935b5d3 100644 --- a/localtime.c +++ b/localtime.c @@ -1951,6 +1951,23 @@ tmcomp(register const struct tm *const atmp, return result; } +/* Copy to *DEST from *SRC. Copy only the members needed for mktime, + as other members might not be initialized. */ +static void +mktmcpy(struct tm *dest, struct tm *const src) +{ + dest->tm_sec = src->tm_sec; + dest->tm_min = src->tm_min; + dest->tm_hour = src->tm_hour; + dest->tm_mday = src->tm_mday; + dest->tm_mon = src->tm_mon; + dest->tm_year = src->tm_year; + dest->tm_isdst = src->tm_isdst; +#if defined TM_GMTOFF && ! UNINIT_TRAP + dest->TM_GMTOFF = src->TM_GMTOFF; +#endif +} + static time_t time2sub(struct tm *const tmp, struct tm *(*funcp)(struct state const *, time_t const *, @@ -1972,17 +1989,7 @@ time2sub(struct tm *const tmp, struct tm yourtm, mytm; *okayp = false; - - yourtm.tm_sec = tmp->tm_sec; - yourtm.tm_min = tmp->tm_min; - yourtm.tm_hour = tmp->tm_hour; - yourtm.tm_mday = tmp->tm_mday; - yourtm.tm_mon = tmp->tm_mon; - yourtm.tm_year = tmp->tm_year; - yourtm.tm_isdst = tmp->tm_isdst; -#if defined TM_GMTOFF && ! UNINIT_TRAP - yourtm.TM_GMTOFF = tmp->TM_GMTOFF; -#endif + mktmcpy(&yourtm, tmp); if (do_norm_secs) { if (normalize_overflow(&yourtm.tm_min, &yourtm.tm_sec, @@ -2289,7 +2296,6 @@ mktime(struct tm *tmp) } #ifdef STD_INSPIRED - time_t timelocal(struct tm *tmp) { @@ -2297,13 +2303,9 @@ timelocal(struct tm *tmp) tmp->tm_isdst = -1; /* in case it wasn't initialized */ return mktime(tmp); } - -time_t -timegm(struct tm *tmp) -{ - return timeoff(tmp, 0); -} - +#else +static +#endif time_t timeoff(struct tm *tmp, long offset) { @@ -2313,7 +2315,18 @@ timeoff(struct tm *tmp, long offset) return time1(tmp, gmtsub, gmtptr, offset); } -#endif /* defined STD_INSPIRED */ +time_t +timegm(struct tm *tmp) +{ + time_t t; + struct tm tmcpy; + mktmcpy(&tmcpy, tmp); + tmcpy.tm_wday = -1; + t = timeoff(&tmcpy, 0); + if (0 <= tmcpy.tm_wday) + *tmp = tmcpy; + return t; +} static int_fast32_t leapcorr(struct state const *sp, time_t t) diff --git a/private.h b/private.h index 7cbd56d2..7320173f 100644 --- a/private.h +++ b/private.h @@ -543,9 +543,24 @@ struct tm *localtime(time_t const *); struct tm *localtime_r(time_t const *restrict, struct tm *restrict); time_t mktime(struct tm *); time_t time(time_t *); +time_t timegm(struct tm *); void tzset(void); #endif +#ifndef HAVE_DECL_TIMEGM +# if (202311 <= __STDC_VERSION__ \ + || defined __GLIBC__ || defined __tm_zone /* musl */ \ + || defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ \ + || (defined __APPLE__ && defined __MACH__)) +# define HAVE_DECL_TIMEGM true +# else +# define HAVE_DECL_TIMEGM false +# endif +#endif +#if !HAVE_DECL_TIMEGM && !defined timegm +time_t timegm(struct tm *); +#endif + #if !HAVE_DECL_ASCTIME_R && !defined asctime_r extern char *asctime_r(struct tm const *restrict, char *restrict); #endif @@ -582,9 +597,6 @@ extern long altzone; # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif -# if TZ_TIME_T || !defined timegm -time_t timegm(struct tm *); -# endif # if TZ_TIME_T || !defined timelocal time_t timelocal(struct tm *); # endif -- 2.37.2

1 0

No Daylight Savings in Fiji For year 2022-2023
by Jashneel Kumar Nov. 9, 2022

Nov. 9, 2022

Dear Timezone Support, I would like to inform you that there will be no Daylight Saving in Fiji this year. Can you please check that the same is reflected in the time zone database. Regards, [New_VF_Icon_RGB_RED] Jashneel Kumar Manager Data Networks & Services Jashneel.Kumar(a)vodafone.com.fj<mailto:Jashneel.Kumar@vodafone.com.fj> Vodafone Fiji PTE Limited, 168 Princes Rd, Tamavua, Suva, Fiji Islands www.vodafone.com.fj<http://www.vodafone.com.fj/> Together we can [Vodafone] ________________________________ The content of this email including any attachments is confidential and may contain information that is proprietary and privileged. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify E-mail Administrator on info(a)vodafone.com.fj Please also destroy and delete this message from your system. Vodafone Fiji PTE Limited does not guarantee that this message is free from computer virus or any other defect. The reader accepts full responsibility for taking defensive and counteractive action needed to rectify the computer virus or other defects caused. Vodafone Fiji PTE Limited : Private Mail Bag, Suva, Fiji | Telephone : +679 3312000 | E-Mail : info(a)vodafone.com.fj Please consider your environmental responsibility before printing this e-mail [https://www.vodafone.com.fj//images/default-source/logo/logo-2x.png] Vodafone Fiji PTE Ltd <https://www.vodafone.com.fj/>

3 5