- tz - lists.iana.org

TZ patch to fix broken link
by Matthew Boynes Sept. 11, 2023

Sept. 11, 2023

Hello TZ group, Attached is a patch to fix a broken link in the africa file. Following the guidelines in the contributions file <https://github.com/eggert/tz/blob/main/CONTRIBUTING>, it sounded like this was the preferred place to email the patch, but please redirect me if it should go elsewhere. Thanks! Matt Boynes

2 1

Danish standard time will probably officially be based on UTC
by Jonas Nyrup Sept. 9, 2023

Sept. 9, 2023

Since 1893-03-29 Danish standard time has been defined as "the mean solar time for the 15th degree of longitude east of Greenwich" (machine translated of the offical law). With the introduction of UTC we didn't update that law, but we did start using UTC+1 as standard time in practice. So for around 50 years maybe only astronomers have been following the law. The Minister of Transportation has now proposed a bill to update the law to define Danish standard time as UTC+1 to keep up with reality. At the first reading all political parties expressed their support and jokingly noted that "it was about time". The updated law is expected to take effect on 2023-03-26. The current law: https://www.retsinformation.dk/eli/lta/1893/83 The bill: https://www.ft.dk/samling/20222/lovforslag/l19/index.htm Tom Scott on the subject: https://www.youtube.com/watch?v=yRz-Dl60Lfc Jonas Nyrup

2 1

Turkey name change
by Letu Yang Sept. 7, 2023

Sept. 7, 2023

I understand this has been discussed last year, but since then both UN and US had adopted the name change from “Turkey” to “ Türkiye”. https://turkiye.un.org/en/184798-turkeys-name-changed-t%C3%BCrkiye Turkey's name changed to Türkiye turkiye.un.org https://www.nytimes.com/2023/01/05/world/middleeast/turkey-spelling-change.… For the State Department, Now It’s Türkiye, Not Turkey nytimes.com Recently Unicode CLDR data has updated the name in CLDR 43 as well. https://cldr.unicode.org/index/downloads/cldr-43 The Turkish government recently asked businesses operating in Türkiye to adopt the new name before the end of the 2023. I think it might be the time for the Turkey Time to be changed to Türkiye Time in tzdata. Letu Yang

5 5

Days since last timezone issue
by Arthur David Olson Sept. 6, 2023

Sept. 6, 2023

https://post.lurk.org/@acousticmirror/111008144295294599/embed @dashdashado

1 0

Re: [tz] Time zone of Mongolia
by Phake Nick Sept. 1, 2023

Sept. 1, 2023

Dear Delgermaa, Specifically when it come to Mongolia, in addition to what have been mentioned by others about start time of DST, can you help confirm status of standard time that have been used across the country now and in the past? Since DST would have to depend on correct standard time information, and despite crrently tz database have tried to use different information sources to figure out what time have been used by different parts of Mongolia, some of the information are in conflicts. Is it correct that currently western part of Mongolia use UTC+7 while rest of the country use UTC+8? And is it correct that Eastern part of the country used UTC+9 in the past but switched to UTC+8 sometimes before year 2008? If this is the case do you know when this happened? Also do you know what's the background of some information from year 2005 claiming that Sükhbaatar Aimag used UTC+8.5 that year? And is there anywhere official where these information can be sourced? Best Regards, Nick. On 2023-09-01 Fri 00:14 UTC, delgermaa.g via tz <tz(a)iana.org> wrote: > Dear sir, madam > > I am contacting from Ministry of digital development and communications > from Mongolia. First let me introduce myself, My name is Delgermaa. I am > officer at Ministry of digital development and communications in Mongolia. > Our country is studying of switching to regular summer time starting from > 2024. In this regard, how many months in advance should your organization > be notified of the time zone change? > > I hope you will soon reply > > Thank you for your cooperation > > Хүндэтгэсэн, > Г.Дэлгэрмаа > ------------------------- > Цахим хөгжил, харилцаа холбооны яамны > > Цахим хөгжлийн бодлогын хэрэгжилтийг > зохицуулах газрын > Нийтийн мэдээллийн дэд бүтцийн хэлтсийн > мэргэжилтэн > Утас: 51-265112, 976-99123321 > www.mddc.gov.mn > > >

1 0

From ministry of digital development and communications
by delgermaa.g Sept. 1, 2023

Sept. 1, 2023

Dear sir, madam I am contacting from Ministry of digital development and communications from Mongolia. First let me introduce myself, My name is Delgermaa. I am officer at Ministry of digital development and communications in Mongolia. Our country is studying of switching to regular summer time starting from 2024. In this regard, how many months in advance should your organization be notified of the time zone change? I hope you will soon reply Thank you for your cooperation Хүндэтгэсэн, Г.Дэлгэрмаа ------------------------- Цахим хөгжил, харилцаа холбооны яамны Цахим хөгжлийн бодлогын хэрэгжилтийг зохицуулах газрын Нийтийн мэдээллийн дэд бүтцийн хэлтсийн мэргэжилтэн Утас: 51-265112, 976-99123321 www.mddc.gov.mn

3 2

DST Chile 2023(tzdb)
by Rodrigo Reyes Aug. 24, 2023

Aug. 24, 2023

Hello, Raising flag about DST change for Chile 2023, official date is 1st September weekend(09/03/2023). But last year the change was delayed to 2nd September weekend(09/11/2023), https://data.iana.org/time-zones/tzdb/NEWS Release 2022b - 2022-08-10 15:38:32 -0700 Briefly: Chile's DST is delayed by a week in September 2022. Iran no longer observes DST after 2022. Rename Europe/Kiev to Europe/Kyiv. New zic -R option Vanguard form now uses %z. Finish moving duplicate-since-1970 zones to 'backzone'. New build option PACKRATLIST New tailored_tarballs target, replacing rearguard_tarballs Do you know what's the way to obtain a confirmation?, and if we have a confirmation about to use the "official date" do you have some SLA to provide a new TZDB to apply this change?. Thks a lot for your answer!!!. Regards Rodrigo Reyes Technologies Manager Phone Number (+56978971585) [cid:image001.png@01D9D52B.766327A0] This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service <https://www.amdocs.com/about/email-terms-of-service>

4 4

System time jumps
by Arthur David Olson Aug. 17, 2023

Aug. 17, 2023

"Windows feature that resets system clocks based on random data is wreaking havoc." https://arstechnica.com/security/2023/08/windows-feature-that-resets-system… @dashdashado

2 1

Fwd: Bulletin C number 66
by Tim Parenti Aug. 14, 2023

Aug. 14, 2023

No leap second 2023-12-31, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Tue, 4 Jul 2023 at 08:06 Subject: Bulletin C number 66 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, 04 July 2023 Bulletin C 66 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of December 2023. 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

What is the "Factory" Zone used for?
by Justin Grant Aug. 10, 2023

Aug. 10, 2023

There's a Zone called "Factory". What is its purpose, and how is it used? Thanks! Justin Grant (I work with ECMA TC39 to make time zones work well in JavaScript)

3 2

[PROPOSED] Document Paraguay’s recently-passed Law No. 7115
by Paul Eggert July 28, 2023

July 28, 2023

This law doesn’t change TZDB’s data; it merely codifies into law recent common practice as implemented by presidential decrees. * southamerica: Add comments re Law No. 7115. --- southamerica | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/southamerica b/southamerica index e55c5f08..9430b185 100644 --- a/southamerica +++ b/southamerica @@ -1697,6 +1697,12 @@ Rule Para 2010 2012 - Apr Sun>=8 0:00 0 - # From Carlos Raúl Perasso (2014-02-28): # Decree 1264 can be found at: # http://www.presidencia.gov.py/archivos/documentos/DECRETO1264_ey9r8zai.pdf +# +# From Paul Eggert (2023-07-26): +# Transition dates are now set by Law No. 7115, not by presidential decree. +# https://www.abc.com.py/politica/2023/07/12/promulgacion-el-cambio-de-hora-s… +# Although Google indexed this government URL, it did not work for me: +# https://www.bacn.gov.py/leyes-paraguayas/11831/ley-n-7115-establece-el-hora… Rule Para 2013 max - Mar Sun>=22 0:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] -- 2.39.2

3 4

[PATCH] Improve touches when making tarballs
by Paul Eggert July 27, 2023

July 27, 2023

* Makefile (SET_TIMESTAMP_N, set-timestamps.out) (tzdata$(VERSION)-rearguard.tar.gz, tzdata$(VERSION)-tailored.tar.gz): Do not use ‘touch -c’, as POSIX says it exits with status 0 even when it fails. Instead, check in the shell that a file exists before touching it. Chatter with “+ touch ...” before touching, to aid debugging of failures. --- Makefile | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index d891f837..68c644d8 100644 --- a/Makefile +++ b/Makefile @@ -958,12 +958,18 @@ $(MANTXTS): workman.sh # plus N if GNU ls and touch are available. SET_TIMESTAMP_N = sh -c '\ n=$$0 dest=$$1; shift; \ - touch -cmr `ls -t "$$@" | sed 1q` "$$dest" && \ + <"$$dest" && \ if test $$n != 0 && \ - lsout=`ls -n --time-style="+%s" "$$dest" 2>/dev/null`; then \ + lsout=`ls -nt --time-style="+%s" "$$@" 2>/dev/null`; then \ set x $$lsout && \ - touch -cmd @`expr $$7 + $$n` "$$dest"; \ - else :; fi' + timestamp=`expr $$7 + $$n` && \ + echo "+ touch -md @$$timestamp $$dest" && \ + touch -md @$$timestamp "$$dest"; \ + else \ + newest=`ls -t "$$@" | sed 1q` && \ + echo "+ touch -mr $$newest $$dest" && \ + touch -mr "$$newest" "$$dest"; \ + fi' # If DEST depends on A B C ... in this Makefile, callers should use # $(SET_TIMESTAMP_DEP) DEST A B C ..., for the benefit of any # downstream 'make' that considers equal timestamps to be out of date. @@ -992,7 +998,8 @@ set-timestamps.out: $(EIGHT_YARDS) --format='tformat:%cd' \ --date='format:%Y-%m-%dT%H:%M:%SZ' \ $$file` && \ - touch -cmd $$time $$file; \ + echo "+ touch -md $$time $$file" && \ + touch -md $$time $$file; \ else \ echo >&2 "$$file: warning: does not match repository"; \ fi || exit; \ @@ -1148,7 +1155,7 @@ tzdata$(VERSION)-rearguard.tar.gz: rearguard.zi set-timestamps.out sed '1s/$$/-rearguard/' <version >$@.dir/version : The dummy pacificnew pacifies TZUpdater 2.3.1 and earlier. $(CREATE_EMPTY) $@.dir/pacificnew - touch -cmr version $@.dir/version + touch -mr version $@.dir/version LC_ALL=C && export LC_ALL && \ (cd $@.dir && \ tar $(TARFLAGS) -cf - \ @@ -1172,7 +1179,7 @@ tzdata$(VERSION)-tailored.tar.gz: set-timestamps.out `test $(DATAFORM) = vanguard || echo pacificnew` (grep '^#' tzdata.zi && echo && cat $(DATAFORM).zi) \ >$@.dir/etcetera - touch -cmr tzdata.zi $@.dir/etcetera + touch -mr tzdata.zi $@.dir/etcetera sed -n \ -e '/^# *version *$.*$/h' \ -e '/^# *ddeps */H' \ @@ -1183,7 +1190,7 @@ tzdata$(VERSION)-tailored.tar.gz: set-timestamps.out -e 's/ /-/g' \ -e 'p' \ <tzdata.zi >$@.dir/version - touch -cmr version $@.dir/version + touch -mr version $@.dir/version links= && \ for file in $(TZDATA_DIST); do \ test -f $@.dir/$$file || links="$$links $$file"; \ -- 2.39.2

1 0

[PATCH] Port better to POSIX 'touch'
by Paul Eggert July 26, 2023

July 26, 2023

* Makefile (set-timestamps.out): Use POSIX syntax for 'touch -d' rather than relying on a GNU extension. --- Makefile | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 17e73891..d891f837 100644 --- a/Makefile +++ b/Makefile @@ -988,8 +988,11 @@ set-timestamps.out: $(EIGHT_YARDS) rm -f test.out && \ for file in $$files; do \ if git diff --quiet $$file; then \ - time=`git log -1 --format='tformat:%ct' $$file` && \ - touch -cmd @$$time $$file; \ + time=`TZ=UTC0 git log -1 \ + --format='tformat:%cd' \ + --date='format:%Y-%m-%dT%H:%M:%SZ' \ + $$file` && \ + touch -cmd $$time $$file; \ else \ echo >&2 "$$file: warning: does not match repository"; \ fi || exit; \ -- 2.39.2

2 3

Problem with some timezone data from 2023 w/ Java SimpleTimeZone
by Andreas Haumer July 19, 2023

July 19, 2023

Hi! [I hope this is the right place to report this problem. I reported it on OpenSUSE bugzilla, but was asked to report it upstrem, too. See https://bugzilla.opensuse.org/show_bug.cgi?id=1213470 for my original bugreport] A few days ago I found that with the 2023c timezone database as installed on OpenSUSE LEAP or RedHat Fedora there are two timezones which produce an IllegalArgumentException in the SimpleTimeZone Java class (from OpenJDK 17): "Asia/Gaza" and "Asia/Hebron" The following small Java programm demonstrates the problem: andreas@localhost:~> cat TimeZoneTest.java import java.util.TimeZone; public class TimeZoneTest { public static void main(String[] argv) { for (final String id : TimeZone.getAvailableIDs()) try { TimeZone.getTimeZone(id).toString(); } catch (Exception ex) { System.out.println("TimeZone " + id + " failed: " + ex); } } } Running this programm with a current Java timezone database installed gives the following output: andreas@localhost:~> java TimeZoneTest.java TimeZone Asia/Gaza failed: java.lang.IllegalArgumentException: Illegal daylight saving value: 0 TimeZone Asia/Hebron failed: java.lang.IllegalArgumentException: Illegal daylight saving value: 0 andreas@localhost:~> rpm -q timezone-java timezone-java-2023c-150000.75.23.1.noarch andreas@localhost:~> java -version openjdk version "17.0.7" 2023-04-18 OpenJDK Runtime Environment (build 17.0.7+0-suse-150400.3.24.1-x8664) OpenJDK 64-Bit Server VM (build 17.0.7+0-suse-150400.3.24.1-x8664, mixed mode, sharing) This is with OpenSUSE LEAP 15.4 and 15.5 I also see the same exceptions with Fedora 37, which also uses a separate 2023c timezone database for Java. Debian based systems (like Debian 11, Debian 12 or Ubuntu 22) run the above program without error. They use the internal tzdb which comes with OpenJDK. It looks like the timezone database contains a 0 for the dstSavings property. The constructor for the SimpleTimeZone Java class wants this calue to be > 0 and throws an IllegalArgumentException if it isn't: public SimpleTimeZone(int rawOffset, String ID, int startMonth, int startDay, int startDayOfWeek, int startTime, int startTimeMode, int endMonth, int endDay, int endDayOfWeek, int endTime, int endTimeMode, int dstSavings) { setID(ID); this.rawOffset = rawOffset; this.startMonth = startMonth; this.startDay = startDay; this.startDayOfWeek = startDayOfWeek; this.startTime = startTime; this.startTimeMode = startTimeMode; this.endMonth = endMonth; this.endDay = endDay; this.endDayOfWeek = endDayOfWeek; this.endTime = endTime; this.endTimeMode = endTimeMode; this.dstSavings = dstSavings; // this.useDaylight is set by decodeRules decodeRules(); if (dstSavings <= 0) { throw new IllegalArgumentException("Illegal daylight saving value: " + dstSavings); } } So: is this a problem with the timezone database or rather a problem with the implementation of the Java SimpleTimeZone class? Thanks! - andreas -- Andreas Haumer *x Software + Systeme | mailto:andreas@xss.co.at Karmarschgasse 51/2/20 | https://www.xss.co.at/ A-1100 Vienna, Austria | Tel: +43-1-6060114-0

3 2

Issue with timezone
by Ty Hanks July 18, 2023

July 18, 2023

Having an issue with timezone ‘America/Bogota’ should be the same as ‘America/NewYork’ but if you pull time based on it from pytz which uses your database. You get the wrong timezone a 3 or 4 hour ahead timezone. Feel free to ask for more testing info if needed .. Thanks

4 3

TZDB 2023c build issues with ARM busybox
by Rajesh Subramanian July 11, 2023

July 11, 2023

Hi Team, I am trying to compile the TZDB in ARM busysbox version: 2023c After compiling the executable during the installation stage, got an error while trying to create the timezone files using tzdata.zi. Could you please help on what is wrong here? make BACKWARD='backward' DESTDIR='/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/niagara-staging/tmp/tz' LEAPSECONDS='' PACKRATDATA='' PACKRATLIST='' TZDEFAULT='/etc/localtime' TZDIR='/usr/share/zoneinfo' ZIC='./zic ' LEAPSECONDS= install_data make[1]: Entering directory '/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/tz/tz-2023c' ./zic -v -d '/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/niagara-staging/tmp/tz/usr/share/zoneinfo' tzdata.zi *./zic: 1: Syntax error: word unexpected (expecting ")")* make[1]: *** [Makefile:697: install_data] Error 2 File format for the executable: file zic is linked with the expected host architecture. *zic*: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=48cd5d62692908a4f58468f5077d4187fe06c825, not stripped Regards, Rajesh

4 3

Error in Scandinavian tz data
by Anders Rosendahl June 28, 2023

June 28, 2023

Hello! I'm developing an application using the JavaScript Intl API (which is relying on the IANA tz db) for converting between local time and UTC. I started receiving error reports from users about wrong calculations (particularly from Denmark in the 1940's), and I discovered that in some cases daylight saving time was applied in a way not in accordance to historical facts. I investigated the IANA tz database files and I discovered that a change has happened in version 2022b (in the file "europe"). Compared to the earlier version (2022a), 4 zones seem to have their rules removed and instead linked to Europe/Berlin: Link Europe/Berlin Arctic/Longyearbyen Link Europe/Berlin Europe/Copenhagen Link Europe/Berlin Europe/Oslo Link Europe/Berlin Europe/Stockholm This, evidently, is not correct, and will result in erroneous results for these zones. Best wishes, Anders Rosendahl

7 11

Re: [tz] [libc-coord] thread-safe localtime() for an arbitrary timezone
by Paul Eggert June 21, 2023

June 21, 2023

On 2023-06-15 10:03, enh wrote: > any thoughts on either renaming `struct state` (i went with `struct > __timezone_t` to match the typedef to timezone_t for the pointer) or having > a knob for that (i added a `#define state __timezone_t` in the `#if > NETBSD_INSPIRED` in private.h)? why do i care? because tzcode pulls in the > system <time.h>, which is actually fine for the tzcode code, but breaks the > OpenBSD wcsftime(). We could rename 'struct state', but I'm a bit lost as to what the problem is, as I don't see mention of 'state' or 'timezone_t' in openbsd/lib/libc/time/wcsftime.c. Although there is a 'struct state' in openbsd/lib/libc/time/localtime.c I assume you're replacing that with tzcode's localtime.c somehow. User apps (which tzcode is, by default) shouldn't define symbols like __timezone_t because these symbols are reserved to the system. We could easily rename 'struct state' to 'struct timezone_struct' so that you could compile with -Dtimezone_struct=__timezone_t, though I'm still curious about why 'struct state' causes problems. I'll cc this to the tz mailing list to see whether other people there have insight into this issue. For those new to the discussion, the original thread is archived here: https://www.openwall.com/lists/libc-coord/2023/06/14/1

4 14

Iran Time Zone is Incorrect in Your Database
by Mohammad Ahmadian June 2, 2023

June 2, 2023

Hello, Thanks for your service. This year, the Iran government decided to cancel the daylight time zone. So they did not change the time zone to 04:30. It is now 03:30. I updated my tablet via this application to the latest version of your database successfully: https://github.com/meefik/tzupdater But the time zone is wrongly 04:30 again. Please change your database. Let me know what you think and do. Thank you

2 1

Tzdb build issue
by Naveen kumar June 1, 2023

June 1, 2023

Hi Team, I am facing this issue while compiling the tzdata latest version tzdb-2023c.I attached the log for your reference. Thanks, Naveen.

4 9

[PROPOSED] Update tzselect comment
by Paul Eggert June 1, 2023

June 1, 2023

* tzselect.ksh: Update comment, as Oracle has extended the end-of-life date for Solaris 10. --- tzselect.ksh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzselect.ksh b/tzselect.ksh index 9a91acfc..98774c03 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -21,7 +21,7 @@ REPORT_BUGS_TO=tz(a)iana.org # MirBSD Korn Shell <http://www.mirbsd.org/mksh.htm> # # For portability to Solaris 10 /bin/sh (supported by Oracle through -# January 2024) this script avoids some POSIX features and common +# January 2025) this script avoids some POSIX features and common # extensions, such as $(...) (which works sometimes but not others), # $((...)), ! CMD, ${#ID}, ${ID##PAT}, ${ID%%PAT}, and $10. -- 2.39.2

2 1

[PATCH] Ask for POSIX-conforming ‘make’
by Paul Eggert May 31, 2023

May 31, 2023

* Makefile (.POSIX): New target. I discovered the need for this when I ran ‘make -n’ and GNU Make executed recipe lines containing $(MAKE) even though they had side effects. When run in POSIX mode, GNU Make won’t execute recipe lines unless they begin with ‘+’. POSIX says the behavior of ‘make’ is undefined unless the Makefile’s first non-comment line has a ‘.POSIX’ target. --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index 8017a14e..da3ee259 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,6 @@ # Make and install tzdb code and data. +# Request POSIX conformance; this must be the first non-comment line. +.POSIX: # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. -- 2.39.2

1 0

Europe/Tiraspol problem
by Yoshito Umaoka May 19, 2023

May 19, 2023

Dear all, I was looking at some Unicode ICU test failure on Ubuntu related to time zone. ICU utilizes TZ database including backward file. In backward file, Europe/Tiraspol is defined as a link of Europe/Chisinau. So the actual rule is coming from Europe/Chisinau as below (2023c) # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Europe/Chisinau 1:55:20 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT 1:44:24 - BMT 1931 Jul 24 # Bucharest MT 2:00 Romania EE%sT 1940 Aug 15 2:00 1:00 EEST 1941 Jul 17 1:00 C-Eur CE%sT 1944 Aug 24 3:00 Russia MSK/MSD 1990 May 6 2:00 2:00 Russia EE%sT 1992 2:00 E-Eur EE%sT 1997 # See Romania commentary for the guessed 1997 transition to EU rules. 2:00 Moldova EE%sT I found behavior of Europe/Tiraspol is different on Ubuntu. When I set Europe/Tiraspol as the system time zone, the default offset set to timezone variable becomes -10800 (3 hour ahead of UTC). However, Europe/Chisinau above shows it should be -7200 (2 hour ahead of UTC) at this moment. (POSIX timezone variable should store “standard offset”, not counting daylight adjustment). On Ubuntu, when I set Europe/Tiraspol as system time zone, -10800 is set to timezone variable. However, when I set Europe/Chisinau, it changes to -7200. Then I realized Ubuntu is using backzone file, which contains different rule. In backzone file, Europe/Tiraspol is defined as below (2023c) # Moldova / Transnistria Zone Europe/Tiraspol 1:58:32 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT 1:44:24 - BMT 1931 Jul 24 # Bucharest MT 2:00 Romania EE%sT 1940 Aug 15 2:00 1:00 EEST 1941 Jul 17 1:00 C-Eur CE%sT 1944 Aug 24 3:00 Russia MSK/MSD 1991 Mar 31 2:00 2:00 Russia EE%sT 1992 Jan 19 2:00 3:00 Russia MSK/MSD I understand backzone was created for preserving zone definition of some locations which only differs pre-1970 date, and these data might not be reliable. In reality, I think most of TZ database consumer still rely on either backward or backzone for backward compatibility. I think it’s problematic if these two files produce different results today. I guess the zone definition in backzone file might be outdated, and Tiraspol is actually UTC+2/+3. -Yoshito

2 1

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

Changes to DST in IR/Tehran timezone
by Jafari Abolfazl May 16, 2023

May 16, 2023

Hello. First of all thanks for maintaining database and second I hav to excuse for my English before hand, cause I am not a native and maybe do some mistakes. Due to goverments choices, starting from 21st March 2023, Iran dismissed DST and now time should stay at +3:30, but due to lack of contacting with official channels, it seems lots of systems still use 2023c tz database and time is +4:30. This problem cause so many problem specially in smartphone that due to lack of automatic time, many application won't work correctly.

3 2