- tz - lists.iana.org

not getting proper timezone for few countries
by Bhardwaj, vanshika Jan. 18, 2023

Jan. 18, 2023

Hello , We are using tzdata vendor source latest version which is 2022g in our code ,which basically return the timezones value of the country as per the mapping but we found for few of the countries we are getting alphanumeric value as an output of time-zone, like if we select India so timezones we are getting for India is IST as an output which is expected ,but if we select brasalia so timezones for Brasalia we are getting is -03 , which is alpha-numeric value , so can u please tell us when u are going to add the timezones for the rest of the countries or it will be same. Hope u will reply soon. With Regards, Vanshika Bhardwaj Associate Engineer(Eaton)

2 1

Swiss time selectable for Germany
by Benjamin Drung Jan. 17, 2023

Jan. 17, 2023

Hi, I tried tzselect for Germany and was presented with following question: Please select one of the following timezones. 1) Swiss time 2) Germany (most areas), Scandinavia We do not use Swiss time in Germany. I did some research: Germany switched to summertime in 1980 and Swiss in 1981. There is Büsingen am Hochrhein which followed Swiss and therefore deviated from Germany only in 1980. Should zone1970.tab reflect the current status (i.e. drop DE from Europe/Zurich and rename "Germany (most areas)" to "Germany" in the comments)? -- Benjamin Drung Debian & Ubuntu Developer

10 23

[PROPOSED] Be more consistent about MSK/MSD
by Paul Eggert Jan. 17, 2023

Jan. 17, 2023

* NEWS: Mention this. * europe (Europe/Volgograd, Europe/Kirov): Use the abbreviations MSK/MSD when using Moscow time, since that’s what other Russian timezones do. This fixes an inconsistency introduced in 2016g. --- NEWS | 6 ++++++ europe | 18 +++++++++--------- 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 7bd80803..fc35046c 100644 --- a/NEWS +++ b/NEWS @@ -26,6 +26,12 @@ Unreleased, experimental changes since 1970. (Thanks to Almaz Mingaleev.) This affects some pre-1948 timestamps. The old data are now in 'backzone'. + Changes to past time zone abbreviations + + When observing Moscow time, Europe/Kirov and Europe/Volgograd now + use the abbreviations MSK/MSD instead of numeric abbreviations, + for consistency with other timezones observing Moscow time. + Changes to code You can now tell tzselect local time, to simplify later choices. diff --git a/europe b/europe index 89bc3a28..b784d0ee 100644 --- a/europe +++ b/europe @@ -2656,13 +2656,13 @@ Zone Europe/Volgograd 2:57:40 - LMT 1920 Jan 3 3:00 - +03 1930 Jun 21 4:00 - +04 1961 Nov 11 4:00 Russia +04/+05 1988 Mar 27 2:00s - 3:00 Russia +03/+04 1991 Mar 31 2:00s + 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 4:00 - +04 1992 Mar 29 2:00s - 3:00 Russia +03/+04 2011 Mar 27 2:00s - 4:00 - +04 2014 Oct 26 2:00s - 3:00 - +03 2018 Oct 28 2:00s + 3:00 Russia MSK/MSD 2011 Mar 27 2:00s + 4:00 - MSK 2014 Oct 26 2:00s + 3:00 - MSK 2018 Oct 28 2:00s 4:00 - +04 2020 Dec 27 2:00s - 3:00 - +03 + 3:00 - MSK # From Paul Eggert (2016-11-11): # Europe/Saratov covers: @@ -2693,11 +2693,11 @@ Zone Europe/Saratov 3:04:18 - LMT 1919 Jul 1 0:00u Zone Europe/Kirov 3:18:48 - LMT 1919 Jul 1 0:00u 3:00 - +03 1930 Jun 21 4:00 Russia +04/+05 1989 Mar 26 2:00s - 3:00 Russia +03/+04 1991 Mar 31 2:00s + 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 4:00 - +04 1992 Mar 29 2:00s - 3:00 Russia +03/+04 2011 Mar 27 2:00s - 4:00 - +04 2014 Oct 26 2:00s - 3:00 - +03 + 3:00 Russia MSK/MSD 2011 Mar 27 2:00s + 4:00 - MSK 2014 Oct 26 2:00s + 3:00 - MSK # From Tim Parenti (2014-07-03), per Oscar van Vlijmen (2001-08-25): # Europe/Samara covers... -- 2.37.2

1 0

localtime_r multiple times slower for Europe/Moscow timezone
by Benjamin Drung Jan. 11, 2023

Jan. 11, 2023

Hi, a Ubuntu user has been reporting in https://launchpad.net/bugs/868395 that the Europe/Moscow timezone is multiple times slower than other timezones. Here is the example bug.c code: ``` #include <time.h> #include <stdio.h> int main() { time_t t = time(0); int i; struct tm result; for(i=0; i < 10000000; i++) localtime_r(&t, &result); puts(ctime(&t)); return 0; } ``` Compile and run this code: ``` gcc -o bug bug.c time TZ=Etc/UTC ./bug time TZ=Europe/Berlin ./bug time TZ=Europe/Moscow ./bug ``` The result on my machine is that Etc/UTC, Europe/Berlin, and other timezones take around 250 to 400 ms, but Europe/Moscow takes 1200 ms. The result is the same when running in a Debian unstable, Ubuntu 22.04 (jammy) and Ubuntu 23.04 (lunar) chroot. Is that a bug? If yes, is that a bug in glibc? -- Benjamin Drung Debian & Ubuntu Developer

5 6

[PROPOSED 1/2] Fix stray ‘\’ in tzselect
by Paul Eggert Jan. 11, 2023

Jan. 11, 2023

* tzselect.ksh: Remove stray backslash that messed up the wording of a diagnostic. This glitch was introduced in commit 13980693084c36e0275828d8d46d9d9e8975be0d dated Wed Jun 27 11:24:09 2018 -0700. --- tzselect.ksh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzselect.ksh b/tzselect.ksh index 87baaa5..cbfc677 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -401,7 +401,7 @@ while BEGIN { FS = "\t" } { print $NF } '` - echo >&2 'Please select one of the following timezones,' \ + echo >&2 'Please select one of the following timezones,' echo >&2 'listed roughly in increasing order' \ "of distance from $coord". doselect $regions -- 2.39.0

1 1

[PROPOSED] Omit check_sorted dependencies no longer needed
by Paul Eggert Jan. 10, 2023

Jan. 10, 2023

* Makefile (check_sorted): Omit unnecessary dependencies on iso3166.tab, zone.tab, zone1970.tab. They should have been removed in commit 1bb4263bb1716fe3ba63b26600adc9c32f1fe16e dated 2019-06-22 13:55:46 -0700. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 8bee50d..721a745 100644 --- a/Makefile +++ b/Makefile @@ -837,7 +837,7 @@ check_slashed_abbrs: $(TDATA_TO_CHECK) CHECK_CC_LIST = { n = split($$1,a,/,/); for (i=2; i<=n; i++) print a[1], a[i]; } -check_sorted: backward backzone iso3166.tab zone.tab zone1970.tab +check_sorted: backward backzone $(AWK) '/^Link/ {printf "%.5d %s\n", g, $$3} !/./ {g++}' \ backward | LC_ALL=C sort -cu $(AWK) '/^Zone/ {print $$2}' backzone | LC_ALL=C sort -cu -- 2.39.0

1 0

(no subject)
by Alfred Finamore Jan. 10, 2023

Jan. 10, 2023

Request

1 0

Re: [tz] tz Digest, Vol 136, Issue 11
by nadir altinbas Jan. 8, 2023

Jan. 8, 2023

There are 195 countries in the world today.As mentioned in ( https://www.worldometers.info/geography/how-many-countries-are-there-in-the…) About Today's Topics:. T?rkiye (Jonathan Leffler); My own comment is to be written as" Republic of Turkiye (Turkiye) " Thank Nadir Altinbas e:nadiraltinbas@yahoo.com n.altinbas On Sunday, January 8, 2023 at 03:00:07 PM GMT+3, tz-request(a)iana.org <tz-request(a)iana.org> wrote: Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://mm.icann.org/mailman/listinfo/tz or, via email, send a message with subject or body 'help' to tz-request(a)iana.org You can reach the person managing the list at tz-owner(a)iana.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..." Today's Topics: 1. T?rkiye (Jonathan Leffler) ---------------------------------------------------------------------- Message: 1 Date: Sat, 7 Jan 2023 21:47:15 -0700 From: Jonathan Leffler <jonathan.leffler(a)gmail.com> To: Time Zone Mailing List <tz(a)iana.org> Subject: [tz] T?rkiye Message-ID: <CAH+RLGEKNgZK4c9e4rdO6nmU-tMHnZ3+cXMV9=6LVaJ7VvDAJg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" >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

Türkiye
by Jonathan Leffler Jan. 8, 2023

Jan. 8, 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