- tz - lists.iana.org

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

Web sites using recent versions of the tz database
by Sylvia May 10, 2023

May 10, 2023

Dear team, My name is Silvia, I am the webmaster responsible for carta-natal.es. This is an astrology website wich uses the latest version of the TZ database for calculating astral charts with the correct UT hour and date. It includes a section where you can see the timezone details and time changes of each town throughout history: https://carta-natal.es/zona_horaria.php https://carta-natal.es/cambios_horarios.php Of course there could be some (mine/human) error in associating a time zone identifier to each locality. Do you think it would be possible and/or useful to add carta-natal.es to the web sites list at https://carta-natal.es/cambios_horarios.php? Thank you very much. kind regards, Silvia

1 1

More prominent/consistent record of rule change notification date?
by Jan Harris May 8, 2023

May 8, 2023

Greetings I deal with getting the TZ updates rolled out for IBM AIX. As we all know, sometimes IANA is notified in the eleventh hour, and it is not feasible for AIX to deliver fixes in a matter of weeks (or less) Take Egypt, for example. For good reason, IANA did initiate a new build on March 1, as discussed in this thread<https://mm.icann.org/pipermail/tz/2023-March/032683.html>. (Even if they did, it would have been a tight schedule for AIX to have ready mid April.) I certainly appreciate the emphasis on notifications, placed in the IANA article. How Time Zones Are Coordinated<https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03…> * https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03… I have incorporated this message in to our AIX TZ documentation. We usually see some attribution to the notification in the NEWS Starting in 2023, Egypt will observe DST from April's last Friday through October's last Thursday. (Thanks to Ahmad ElDardiry.) Assume the transition times are 00:00 and 24:00, respectively. I think it would be helpful if there was a clear record of WHEN IANA is officially notified of TZ changes, so users could understand this is the result of their government changes, and notification processes, it is not a "defect" in how IANA or vendors roll out these updates. I do realize that sometimes “official” notifications seems to be that someone submitted a more formal government reference, instead of a news article. Maybe just an indicator of when the group is provided such official confirmation. Thanks for your consideration! Jan Harris SME: Globalization, Graphics, X11, Desktop, Commands/Auth AIX Development Support Organization - IBM O: Austin, TX 901:3i019 Ph: 1-512-286-5445 Jabber:23635445 E: janhar(a)us.ibm.com <mailto:janhar@us.ibm.com>

6 8

Inconsistencies between backward and backzone
by Benjamin Drung May 4, 2023

May 4, 2023

Hi, building tz with PACKRATDATA=backzone should result in time zones that only differ for dates before 1970. For dates after 1970 they should be identical to not building with PACKRATDATA=backzone (using backzone to create symlinks). But there are four (five if you include Pacific/Enderbury) time zones that has different UTC offset nowadays: * America/Ensenada differs from America/Tijuana * Asia/Kashgar differs from Asia/Urumqi * Atlantic/Jan_Mayen differs from Europe/Berlin * Europe/Tiraspol differs from Europe/Chisinau First investigation indicate that the timezones in backzone did not get the recent updates applied to them. -- Benjamin Drung Debian & Ubuntu Developer

2 3

Introduce Etc/UTC+x timezones?
by Benjamin Drung May 4, 2023

May 4, 2023

Hi, If people are aware of timezones, they often know UTC and their offsets (e.g. Europe/Berlin is UTC+2 summer). But they are probably not aware that the Etc/GMT offsets are inverted (e.g. you have to select Etc/GMT-2 for UTC+2). I was not aware of that and other people as well as the bugs in Ubuntu and Debian indicate (see https://launchpad.net/bugs/1325949 and https://bugs.debian.org/540305) What do you think about the idea of introducing Etc/UTC+x timezones that have the "correct" offset so that people can select fixed offsets more easily? So Etc/GMT-2 would be renamed to Etc/UTC+2 and Etc/GMT-2 would become a symlink to it (same for all other Etc/GMT+x and Etc/GMT-x timezones). -- Benjamin Drung Debian & Ubuntu Developer

16 31

DST changes for Egypt
by Eugen Cravciuc May 3, 2023

May 3, 2023

Hi. May you please update the values for the DST Egypt? Thank you https://www.timeanddate.com/time/change/egypt

2 1

offtime_r
by Dag-Erling Smørgrav April 26, 2023

April 26, 2023

The tzcode distribution includes a (non-standard and undocumented) offtime() function but no offtime_r() function, which seems like an oversight. The attached patch (relative to 2023c) adds it. Regards, Dag-Erling

2 3

Change Chile/Santiago DST
by Antonio Afranio Barbosa Martins April 26, 2023

April 26, 2023

Hi there, There is a issue with Daylight Saving Time (DST) for Chile/Santiago (South America). Based on some sites like https://www.timeanddate.com/time/zone/chile/santiago and https://www.bcn.cl/leychile/navegar?i=1179983&f=2022-08-13 (oficial Chile resolution) Correct time: Year Daily Time Change 2022 Sun, 3 Apr, 00:00 -1 hour (DST end) Sun, 11 Sep, 00:00 +1 hour (DST start) 2023 Sun, 2 Apr, 00:00 -1 hour (DST end) Sun, 3 Sep, 00:00 +1 hour (DST start) 2024 Sun, 7 Apr, 00:00 -1 hour (DST end) Sun, 8 Sep, 00:00 +1 hour (DST start) 2025 Sun, 6 Apr, 00:00 -1 hour (DST end) Sun, 7 Sep, 00:00 +1 hour (DST start) 2026 Sun, 5 Apr, 00:00 -1 hour (DST end) Sun, 6 Sep, 00:00 +1 hour (DST start) Descarga de Responsabilidad: Este mensaje contiene información confidencial y esta dirigido solamente al remitente especificado. Si usted no es el destinatario no debe tener acceso, distribuir ni copiar este e-mail. Notifique por favor al remitente inmediatamente si usted ha recibido este mensaje por error y eliminelo de su sistema. La transmisión del e-mail no se puede garantizar que sea segura, sin errores o como que la información podría ser interceptada, alterada, perdida, destruida, llegar atrasado, incompleto o contener virus, por lo tanto el remitente no acepta la responsabilidad por ningunos de los errores u omisiones en el contenido de este mensaje, que se presentan como resultado de la transmisión del e-mail. Si la verificación se requiere, por favor solicite una versión impresa. Disclaimer: This message contains confidential information and is intended only for recipient specified. If you are not recipient you should not disseminate, distribute or copy this e-mail. Please notify to sender immediately if you have received this message by mistake and delete this from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The receptor therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version.

2 2