- tz - lists.iana.org

Türkiye
by Jonathan Leffler Jan. 7, 2023

Jan. 7, 2023

>From the Los Angeles Times, 2023-01-05 (summary from an email dated 2023-01-06): Ceding to a longstanding Turkish demand, the State Department on Thursday > agreed to begin spelling the country’s name in Turkish > <https://click.email.latimes.com/?qs=fff6b852d8f4b17927eabd337816fdb1705edee…> in > its official documents. Turkey will now be referred to as “Türkiye,” > Wilkinson reported. https://www.latimes.com/politics/story/2023-01-05/state-department-will-now… -- 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

Re: [tz] ptrdiff_t changes in tzcode
by Paul Eggert Jan. 7, 2023

Jan. 7, 2023

On 2022-12-12 08:12, Christos Zoulas wrote: > How about changing it then to be: > > sum <= (ptrdiff_t)min(PTRDIFF_MAX, SIZE_MAX) > > This does the check explicitly and avoids the signed/unsigned warning? It is also what the #else part of the code does... This pattern > lives in many places, so we could put the RHS of the expression to a #define? Sure, we can do that. The attached proposed patch (installed in the development repository) uses a new macro INDEX_MAX to capture this notion. This shouldn't change behavior (or even generated code) but can help clarify things. (Although I'm not a fan of casts I don't see how to avoid it here.) >>> There are also a bunch of places now where you get sign comparison warnings (where ptrdiff_t is compared to size_t, like sizeof() or >>> the result of strlen(3). That's OK, they're false alarms: GCC and Clang go overboard in this department. To pacify the compilers you can compile with -Wno-sign-compare as suggested in Makefile's GCC_DEBUG_FLAGS macro. > I think that the ptrdiff_t changes make things more complicated... Yes, it's a tradeoff between complexity now, and simplicity/safety in the long run. Once we can assume C23 (say, 30 years from now!) we can get rid of the trickier code that ports to C17 and earlier. In the meantime as C23 becomes more popular we can start using the simpler code. (I did resist the temptation in the tricky code to write "itemsize**nitems_alloc", which though correct doesn't mean what it looks like....) >> By the way, I'd been meaning to try to sync tzdb localtime.c with NetBSD's at some point. Shouldn't be that hard, I'd think, and might help get bugs fixed faster (in both directions). > > That would be great! OK, thanks, I'll add that to my list of things to do.

6 14

Split America into North America and South America
by Benjamin Drung Jan. 7, 2023

Jan. 7, 2023

Hi, debconf [1] for the tzdata Debian/Ubuntu package ask for the geographic area (e.g. Europe, Asia, etc) and then for the city inside this area. The resulting timezone is $area/$city. While working on the debconf template, I noticed that the America directory is the biggest with 157 cities. Having to find the correct city in that big list can take some time. The second biggest area is Asia with 90 countries. The timezones are split by continent/ocean. The Afro-Eurasia continent is split into Africa, Asia, Europe, but America is not split into North America and South America. For consistency I suggest to split America into North America and South America to have all seven continents present [2]. The git repository already separate northamerica and southamerica files. [1] https://en.wikipedia.org/wiki/Debian_configuration_system [2] https://en.wikipedia.org/wiki/Continent -- Benjamin Drung Debian & Ubuntu Developer

7 8

Re: [tz] Split America into North America and South America
by dpatte Jan. 6, 2023

Jan. 6, 2023

Personally, I'd like to at least see 'America' renamed 'Americas', to both differentiate from the nickname for the USA, and to show there two continents (by traditional naming). ----- Original Message ----- From: Clive D.W. Feather via tz [mailto:tz@iana.org] To: "Wolfgang Keller" <wolfgangkeller(a)gmail.com> Cc: tz(a)iana.org Sent: Fri, 6 Jan 2023 21:46:47 +0000 Subject: Re: [tz] Split America into North America and South America Wolfgang Keller via tz said: > Hi, > let us consider what conventions for the number and separations of > continents exist. According to > > https://en.wikipedia.org/w/index.php?title=Continent&oldid=1131827063#N… > there exist (at least) five common conventions for the number and > separation of continents: > > a) 4 continents (Afro-Eurasia (Old World), America (New World), > Australia, Antarctica > b) 5 continents (Africa, Eurasia, America, Antarctica, Australia) > c) 6 continents, combined-Eurasia (Africa, Eurasia, North America, > South America, Antarctica, Australia) > d) 6 continents, combined-America (Africa, Asia, Europe, America, > Antarctica, Australia) > e) 7 continents (Africa, Asia, Europe, North America, South America, > Antarctica, Australia) You've forgotten Zealandia, which some consider to be a continent. > For the prevalence of these separations (prevalence of c)-e) taken > from the linked section of the Wikipedia article) > a) is to my knowledge motivated by geology > c) is is mostly used in Russia and some parts of Eastern Europe. > d) is taught in some countries where Romance languages are spoken and in Greece > e) is the model taught in most English-speaking countries > > So the central question that the problem reduces to is: which > separation of continents should tzdata implicitly endorse by its data > structures? If I were to ask, I would immediately say a) because this > is the only convention of this list that is motivated by science > (geology) and not by politics or history, I disagree. e is justifiable by geography: a continent doesn't have to be the largest contiguous landmass; it can be bordered by an isthmus or mountain range just as much as a puddle. But I don't see the need for this split. The division was made for the few humans who work with the raw data, not for the general public and certainly not for geologists. It works, so don't break it. -- Clive D.W. Feather | If you lie to the compiler, Email: clive(a)davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

2 1

Request for Russian Antarctic stations
by Benjamin Drung Jan. 6, 2023

Jan. 6, 2023

Hi, Ubuntu bug https://launchpad.net/bugs/1457285 requests to add Russian Antarctic research stations to tzdata. They are: AQ -6212-05858 Antarctica/Bellingshausen Bellingshausen Station, Vaterloo Island, GMT-4 AQ -7046+01149 Antarctica/Novolasarevskaya Novolasarevskaya Station, GMT AQ -6739+04530 Antarctica/Molodezhnaya Molodezhnaya Station, GMT+3 AQ -6633+09300 Antarctica/Mirniy Mirniy Station, GMT+7 AQ -6930+15923 Antarctica/Leningradskaya Leningradskaya Station, GMT+10 AQ -7445-13648 Antarctica/Russkaya Russkaya Station, GMT-6 AQ -6922+07623 Antarctica/Progress Progress Station, GMT+5 AQ -6944+07342 Antarctica/Druzhnaya Druzhnaya Station, GMT+5 Please mean that GMT data given are POSIX inversed. -- Benjamin Drung Debian & Ubuntu Developer

5 4

[PROPOSED] A couple more ptrdiff_t overflow safety checks
by Paul Eggert Jan. 4, 2023

Jan. 4, 2023

* private.h (TYPE_BIT): Now returns a signed value. * zdump.c (sumsize, xmalloc): Now takes signed args, like the result. (xstrsize): New function. (tzalloc, saveabbr): Use xstrsize to properly catch strings so long that their sizes do not fit into ptrdiff_t. Although quite implausible in real-life uses, it is possible according to the C standard. --- private.h | 2 +- zdump.c | 28 ++++++++++++++++++++-------- 2 files changed, 21 insertions(+), 9 deletions(-) diff --git a/private.h b/private.h index 03ee4d10..b638e9e4 100644 --- a/private.h +++ b/private.h @@ -805,7 +805,7 @@ ATTRIBUTE_REPRODUCIBLE time_t time2posix_z(timezone_t, time_t); ** Finally, some convenience items. */ -#define TYPE_BIT(type) (sizeof(type) * CHAR_BIT) +#define TYPE_BIT(type) (CHAR_BIT * (ptrdiff_t) sizeof(type)) #define TYPE_SIGNED(type) (((type) -1) < 0) #define TWOS_COMPLEMENT(t) ((t) ~ (t) 0 < 0) diff --git a/zdump.c b/zdump.c index 98537f4e..b93910ed 100644 --- a/zdump.c +++ b/zdump.c @@ -133,9 +133,9 @@ size_overflow(void) } /* Return A + B, exiting if the result would overflow either ptrdiff_t - or size_t. */ + or size_t. A and B are both nonnegative. */ ATTRIBUTE_REPRODUCIBLE static ptrdiff_t -sumsize(size_t a, size_t b) +sumsize(ptrdiff_t a, ptrdiff_t b) { #ifdef ckd_add ptrdiff_t sum; @@ -148,10 +148,22 @@ sumsize(size_t a, size_t b) size_overflow(); } +/* Return the size of of the string STR, including its trailing NUL. + Report an error and exit if this would exceed INDEX_MAX which means + pointer subtraction wouldn't work. */ +static ptrdiff_t +xstrsize(char const *str) +{ + size_t len = strlen(str); + if (len < INDEX_MAX) + return len + 1; + size_overflow(); +} + /* Return a pointer to a newly allocated buffer of size SIZE, exiting - on failure. SIZE should be nonzero. */ + on failure. SIZE should be positive. */ ATTRIBUTE_MALLOC static void * -xmalloc(size_t size) +xmalloc(ptrdiff_t size) { void *p = malloc(size); if (!p) { @@ -253,7 +265,7 @@ tzalloc(char const *val) static ptrdiff_t fakeenv0size; void *freeable = NULL; char **env = fakeenv, **initial_environ; - size_t valsize = strlen(val) + 1; + ptrdiff_t valsize = xstrsize(val); if (fakeenv0size < valsize) { char **e = environ, **to; ptrdiff_t initial_nenvptrs = 1; /* Counting the trailing NULL pointer. */ @@ -410,13 +422,13 @@ saveabbr(char **buf, ptrdiff_t *bufalloc, struct tm const *tmp) if (HAVE_LOCALTIME_RZ) return ab; else { - size_t ablen = strlen(ab); - if (*bufalloc <= ablen) { + ptrdiff_t absize = xstrsize(ab); + if (*bufalloc < absize) { free(*buf); /* Make the new buffer at least twice as long as the old, to avoid O(N**2) behavior on repeated calls. */ - *bufalloc = sumsize(*bufalloc, ablen + 1); + *bufalloc = sumsize(*bufalloc, absize); *buf = xmalloc(*bufalloc); } -- 2.37.2

1 0

Questions on tzname and tm_zone
by Patrik Lantto Dec. 31, 2022

Dec. 31, 2022

Dear all, I have a few questions regarding how the tzdb code handles tzname and tm_zone: * The define HAVE_TZNAME have three different "settings"; 0 if tzname is not supported, 1 to support tzname defined by the system library and 2 to support and define tzname. In the code though, when defining tzname it also adds the value of TZ_TIME_T which reduces the options. Basically, if time_tz is defined to another datatype that time_t, tzname cannot be defined by the system library since setting HAVE_TZNAME to 1 would still define tzname (around line 195 of localtime.c). Is there a reason for this behaviour (which is also similar for USG_COMPAT)? In my platform we define a new 64 bit datatype, but would still need tzname as defined by the system library. * In case of an invalid timezone, the behaviour of tzname and tm_zone behaves differently; tzname would be set to WILDABBR (which is possible to define), but if localtime is called tm_zone will be set to "UTC" while if gmtime is called, tm_zone is set to "-00" and if offtime is called (with a non-0 offset) tm_zone is WILDABBR. It seems somewhat inconsistent, so is this by design? * The way tzname is updated (in settzname) in settzname is that it first set tzname[0] and tzname[1] to either WILDABBR or UTC, and then possibly update with the correct names. While tzname is not considered thread safe, this way writing to tzname twice means that even call to tzset with the same timezone could affect other threads reading tzname. Not a huge risk, but still possible. Is this something to consider in the implementation? * Since tzname is not thread safe, and due to the way tm_zone is handled it is somewhat hard to detect if a TZ string is valid or not. Is there a recommended way to detect an invalid string? Best regards, Patrik Lantto -- Patrik Lantto - patrik.lantto(a)wisi.se - +46 13 210918

2 1

[PROPOSED] Support leap-seconds.list tombstone
by Paul Eggert Dec. 22, 2022

Dec. 22, 2022

From: Paul Eggert <eggert@trombone> This change looks forward to the possibility of leap seconds being discontinued by 2035. If and when that happens, the expiration date on the leap-seconds.list file is likely to stop being maintained, as there will be no need to issue new versions of leap-seconds.list every six months. Although the details have not been decided, for now assume that the last edition of leap-seconds.list will simply lack an expiration-date line. * leapseconds.awk: If the input lacks an expiration line like ‘#@ 3896899200’, do not treat it as if ‘#@ 0’ were present, as that would mean an expiration date of 1900-01-01. Instead, do not output an expiration date; just output a comment saying that there is no expiration date. Similarly for update dates and input lacking lines like ’#$ 3676924800’. --- NEWS | 3 +++ leapseconds.awk | 50 ++++++++++++++++++++++++++++++------------------- 2 files changed, 34 insertions(+), 19 deletions(-) diff --git a/NEWS b/NEWS index 9ac3367..5510823 100644 --- a/NEWS +++ b/NEWS @@ -42,6 +42,9 @@ Unreleased, experimental changes 'restrict' keyword consistently with their documentation. This may allow future optimizations. + leapseconds.awk can now process a leap seconds file that never + expires; this might be useful if leap seconds are discontinued. + Changes to commentary Note that leap seconds are planned to be discontinued by 2035. diff --git a/leapseconds.awk b/leapseconds.awk index b6c48bc..7d2556b 100644 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -104,18 +104,23 @@ BEGIN { } END { - sstamp_to_ymdhMs(expires, ss_NTP) - print "" - print "# UTC timestamp when this leap second list expires." - print "# Any additional leap seconds will come after this." - if (! EXPIRES_LINE) { - print "# This Expires line is commented out for now," - print "# so that pre-2020a zic implementations do not reject this file." + + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + + print "# UTC timestamp when this leap second list expires." + print "# Any additional leap seconds will come after this." + if (! EXPIRES_LINE) { + print "# This Expires line is commented out for now," + print "# so that pre-2020a zic implementations do not reject this file." + } + printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ + EXPIRES_LINE ? "" : "#", \ + ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec + } else { + print "# (No Expires line, since the expires time is unknown.)" } - printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ - EXPIRES_LINE ? "" : "#", \ - ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec # The difference between the NTP and POSIX epochs is 70 years # (including 17 leap days), each 24 hours of 60 minutes of 60 @@ -124,15 +129,22 @@ END { print "" print "# POSIX timestamps for the data in this file:" - sstamp_to_ymdhMs(updated, ss_NTP) - printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - updated - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - sstamp_to_ymdhMs(expires, ss_NTP) - printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - expires - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - + if (updated) { + sstamp_to_ymdhMs(updated, ss_NTP) + printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + updated - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(updated time unknown)" + } + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + expires - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(expires time unknown)" + } printf "\n%s", last_lines } -- 2.38.1

1 0

Re: [tz] [PROPOSED] Mention the planned obsolescence of leap seconds
by Brian Inglis Dec. 22, 2022

Dec. 22, 2022

On 2022-12-20 17:25, Paul Eggert via tz wrote: > + Changes to commentary > + Note that leap seconds are planned to be discontinued by 2035. > + This affects time stamps during the leap second era (1972–2035). > +Leap seconds were introduced in 1972 to accommodate the > +difference between atomic time and the less-regular rotation of the earth. > +Unfortunately they caused so many problems with civil Civil (e.g. legal etc.) time keeping is not the problem, it is mainly proprietary computer systems and applications, not adequately programmed to deal with the realities of time keeping. > +timekeeping that they > +are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned > +to be discontinued by 2035</a>, with some as-yet-undetermined > +mechanism replacing them, perhaps after the year 2135. > +Despite their impending obsolescence, a record of leap seconds is still > +needed to resolve timestamps from 1972 through 2035. I would expect astronomers and physicists to have divergent views, but both use software which handles varieties of time bases, scales, and conversions. It seems likely that other scientists and disciplines with time concerns would line up behind one or the other, depending on whether their focus is civil, geocentric, or longer term in some way, or more artificial on accuracy, calibration, precision or other short term characteristics. > <a href="https://www.ucolick.org/~sla/leapsecs/"><abbr>UTC</abbr> > might be redefined > without Leap Seconds</a> gives pointers on this > +contentious issue. > +The General Conference on Weights and Measures > +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">voted in 2022</a> > +to discontinue the use of leap seconds by 2035, replacing them with an > +as-yet-undetermined scheme some time after the year 2135. Expect every lawyer, in any case involving time stamped records, to jump on the technicality of any significant deviation of time keeping from solar time, which is the legal basis in most English common law jurisdictions, possibly also in some continental code and Scandinavian/Nordic jurisdictions e.g. Denmark: https://www.dr.dk/nyheder/indland/uret-paa-din-telefon-viser-en-ulovlig-tid https://www-dr-dk.translate.goog/nyheder/indland/uret-paa-din-telefon-viser… -- 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

DST in the news
by Arthur David Olson Dec. 22, 2022

Dec. 22, 2022

A 538 piece on the merits and demerits of permanent standard time and permanent daylight time. https://projects.fivethirtyeight.com/daylight-saving-time/ --ado

1 0