November 2019 - tz - lists.iana.org

Italy April 1944 discrepancy between comment and data
by Alois Treindl Oct. 5, 2021

Oct. 5, 2021

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

'Australia/Canberra' time zone?
by John Pye April 24, 2020

April 24, 2020

Hi there I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000. What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion? Here is what I believe to be an official source about the Canberra timezone (at least for the present day): https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-a… Cheers JP

8 19

incorrect timezone info from tar files
by Benjamin Weiser Dec. 8, 2019

Dec. 8, 2019

Hello, I'd like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST. I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST) TimeZone UTC Offset ObservesDST IANA_UTC_offset: IANA_ObservesDST: America/Campo_Grande -4 0 -4 1 America/Sao_Paulo -3 0 -3 1 America/St_Johns -3.5 1 -3 1 Asia/Sakhalin 11 0 10 0 Australia/Adelaide 9.5 1 9 1 Australia/Darwin 9.5 0 9 0 Australia/Lord_Howe 10.5 1 10 1 Europe/Istanbul 3 0 2 1 Indian/Cocos 6.5 0 6 0 Pacific/Chatham 12.75 1 12 1 Thanks.

8 12

Re: [tz] Unnecessary time zones in Ukraine territory
by Mikhail Gribanov Dec. 4, 2019

Dec. 4, 2019

Ping. Please fix the time zones of Ukraine. Or at least reply me. пт, 27 сент. 2019 г. в 20:21, Mikhail Gribanov <mikhail.gribanov(a)gmail.com>: > > Hi. Many Linux distributions use time zones from tz database. But I > noticed that in Ukraine there are two unnecessary time zones. This is > noticeable in the Linux distributions installers when choosing a time > zone. There is only one time zone in Ukraine: > https://uk.wikipedia.org/wiki/Час_в_Україні (Europe/Kiev in tz > database) > > Unnecessary time zones: > Europe/Uzhgorod > Europe/Zaporozhye > > Can you explain why they were added? I did not find any evidence of > the existence of events "Ruthenia used CET 1990/1991" (comment in tz > database). > And if it really existed is it possible to somehow mark them as > inactive time zones? Because many programs (for example, Linux > distribution installers, which I mentioned above) offer to select them > as active, which is incorrect.

4 6

Help on Updating Java Time ZOne
by Santos, Cosme Dec. 3, 2019

Dec. 3, 2019

Hi, I am from brazil and I am trying to fix na issue with java, We used the command Execute C:\Program Files\Java\jdk1.8.0_161\bin>java -jar tzupdater.jar -v -f -l file:c:\temp\tzdata2019c-rearguard.tar.gz (via cmd) And restarted all the Java application, however, some parts of the application are with the correct time, others are not. I have found this link and I am trying to get a fix for this, but I'd like to as for ehlp. What is tzcode and tzdb, should I update them to? Also, the Brazil Timezone change, 2019 we won't have it, so a friend sent me the tzdata2019c-rearguard.tar.gz (is this a good file?) [cid:image001.png@01D5A608.A1816A60] Best Regards, Cosme Santos Services & Support Analyst | South America E-Mail: c.santos(a)asctechnologies.com<mailto:c.santos@asctechnologies.com> I Phone: +55 11 4040-4500 | + 55 11 9 8555-0408 [cid:image002.jpg@01D0FABE.B417E720] ASC WFO Solutions do Brasil Ltda. I Av. Brig. Faria Lima, 1912 - 11° Andar - Cj 11 G I 01451-907 - São Paulo I http://www.asctechnologies.com.br<http://www.asctechnologies.com.br/> Privacy and legal statements can be found at http://asctechnologies.com/english/asc_impressum.html Please follow us on [Emailsignatur_FB]<https://www.facebook.com/ASC.cloud> [Emailsignatur_TW] <https://twitter.com/ASCTechnologies> [Emailsignatur_XG] <https://www.xing.com/company/asctechnologiesag> [Emailsignatur_LIn] <https://www.linkedin.com/company/465821> All statutory information can be found at http://www.asc.de/english/asc_impressum.html

3 2

USG_COMPAT and POSIX and XOPEN macros
by Andras Farkas Dec. 3, 2019

Dec. 3, 2019

I've noticed that USG_COMPAT shouldn't be replaced by XOPEN macros since it's clear USG_COMPAT is meant to be something users of tzcode can toggle. However, if someone has an application where they set _XOPEN_SOURCE to 700 or another value, I wonder if there should be something equivalent to the following in private.h #ifndef USG_COMPAT # ifndef _XOPEN_VERSION # define USG_COMPAT 0 # else # define USG_COMPAT 1 # endif #endif But using _XOPEN_SOURCE instead. (while also retaining the block of code using _XOPEN_VERSION too. I think in cases where both macros are involved, priority should be given to _XOPEN_SOURCE since it's explicitly what an application programmer has asked for) Right now, the code only reads _XOPEN_VERSION (from the OS) but not _XOPEN_SOURCE (from the application) This possibly could also apply to how only _POSIX_VERSION is currently used, but not _POSIX_C_SOURCE (nor the obsolete _POSIX_SOURCE, but that's been superseded for a long time now) This topic originates in this thread: http://mm.icann.org/pipermail/tz/2019-November/028596.html http://mm.icann.org/pipermail/tz/2019-November/thread.html

3 7

Time zone name tangent
by Arthur David Olson Nov. 24, 2019

Nov. 24, 2019

Having read a bit on the United States Board on Geographic Names... https://en.wikipedia.org/wiki/United_States_Board_on_Geographic_Names <https://en.m.wikipedia.org/wiki/United_States_Board_on_Geographic_Names> ...and their best known actions (the renaming of Cape Canaveral to Cape Kennedy and back)... https://www.straightdope.com/columns/read/613/why-did-they-change-the-name-… ...I'm of two minds on the wisdom of having a Board of Time Zone Names.-S @dashdashado

1 0

[PATCH 1/2] * NEWS: Fix release typo in Nuuk change.
by Paul Eggert Nov. 24, 2019

Nov. 24, 2019

--- NEWS | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index c28905b..92bff58 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,17 @@ News for the tz database +Unreleased, experimental changes + + Briefly: + America/Nuuk renamed from America/Godthab. + + Changes to timezone identifiers + + To reflect current usage in English better, America/Godthab has + been renamed to America/Nuuk. A backwards-compatibility link + remains for the old name. + + Release 2019c - 2019-09-11 08:59:48 -0700 Briefly: @@ -55,12 +67,6 @@ Release 2019c - 2019-09-11 08:59:48 -0700 Hong Kong Winter Time, observed from 1941-10-01 to 1941-12-25, is now flagged as DST and is abbreviated HKWT not HKT. - Changes to timezone identifiers - - To reflect current usage in English better, America/Godthab has - been renamed to America/Nuuk. A backwards-compatibility link - remains for the old name. - Changes to code leapseconds.awk now relies only on its input data, rather than -- 2.17.1

1 1

Question about bug seen in OpenBSD and FreeBSD related to tzname
by Andras Farkas Nov. 23, 2019

Nov. 23, 2019

Hello! Earlier this month, I noticed bugs in OpenBSD and FreeBSD related to tzname's values. https://marc.info/?l=openbsd-bugs&m=157379849727998&w=2 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241978 I noticed that both those OSes share relevant code with tzcode. How would I best test this stuff out with a recent release of tzcode? (i.e. how to make sure I'm including headers only from the 2019c tarball and not from my OS, when possible)

7 15

FreeBSD and USG_COMPAT
by Andras Farkas Nov. 23, 2019

Nov. 23, 2019

FreeBSD doesn't support the int daylight or long timezone in time.h itself. tzcode supports them on OSes which already support them, like OpenBSD. I'm trying to figure out if it should be possible to compile tzcode to support daylight and timezone even on OSes which don't support them. I've saved the output of make (both stdout and stderr) when CFLAGS is set to -DUSG_COMPAT=1 alone into usgcompat.txt I've saved the output of make (both stdout and stderr) when CFLAGS is set to '-DUSG_COMPAT=1 -DHAVE_POSIX_DECLS=0' into both.txt What I'm seeing is that the OS's time.h is being included, under both configurations. This topic originated in this thread: http://mm.icann.org/pipermail/tz/2019-November/028596.html http://mm.icann.org/pipermail/tz/2019-November/thread.html

1 1

Question (potential issue) about tzselect.ksh
by Andras Farkas Nov. 23, 2019

Nov. 23, 2019

I noticed tzselect.ksh, despite its filename, uses #!/bin/bash as its shebang. Should the filename be renamed or shebang be switched to ksh? That said, both ksh93 -n and shellcheck don't complain. (other than for `` being used instead of $(), which is a warning rather than an error) This isn't urgent at all, though.

2 2

An update on AP style on Kyiv
by John Hawkinson Nov. 20, 2019

Nov. 20, 2019

I apologize for stirring the pot by contributing to one of our longer-running topics of late, however: https://blog.ap.org/announcements/an-update-on-ap-style-on-kyiv -- jhawk(a)alum.mit.edu John Hawkinson Date: Wed, 14 Aug 2019 14:08:09 -0000 From: "The Definitive Source: <author>" Subject: An update on AP style on Kyiv X-RSS-Feed: https://blog.ap.org/feed.rss X-RSS-ID: https://blog.ap.org/announcements/an-update-on-ap-style-on-kyiv X-RSS-URL: https://blog.ap.org/announcements/an-update-on-ap-style-on-kyiv X-RSS-TAGS: Kyiv,Kiev,Ukraine,AP Style,AP Stylebook,Announcements,featured,Definitive-Source We are making a significant change in our style for the Ukrainian capital city Kiev. It will henceforth be written in text, captions and datelines as Kyiv. URL: https://blog.ap.org/announcements/an-update-on-ap-style-on-kyiv

14 26

Antarctica/Troll time
by Phake Nick Nov. 18, 2019

Nov. 18, 2019

In the Antarctica file of tz database, some rules for Antarctica/Troll have been commented out, with the description of it saying "uncomment them when 2014b is more prevalent". Is it still not prevalent enough to uncomment them now?

4 3

UK Lords "Discontinuing seasonal changes of time" publications
by Paul Eggert Nov. 14, 2019

Nov. 14, 2019

The EU Internal Market Sub-Committee of the UK House of Lords has published oral and written comments on proposals to abolish DST transitions in the UK, and are preparing a report. The main comment that caught my eye was from Google's Jonathan Skeet <https://data.parliament.uk/writtenevidence/committeeevidence.svc/evidencedo…>. Skeet underscores the utility of announcing changes long in advance. He goes into considerable detail about "Europe/London" and other tzdb names, negative DST in the Republic of Ireland, "permanent" DST, "BST" and other time zone labels, and so forth. The complete list of published comments can be found here. This list contains a copy of the comment that I circulated on the tz mailing list on August 5. https://www.parliament.uk/business/committees/committees-a-z/lords-select/e…

1 0

uptodate data
by Jean Nov. 14, 2019

Nov. 14, 2019

6 8

Change DTS and time zone for Morocco
by liuchao (CR) Nov. 12, 2019

Nov. 12, 2019

In the past, Morocco observed four clock changes per year. Like in most other countries with seasonal time changes, the DST period in Morocco started in the spring and ended in the fall (autumn). However, clocks were turned back to standard time during the Islamic month of Ramadan to make it easier to observe the daytime fast. The Kingdom of Morocco now remains permanently set to UTC+01:00 instead of following an earlier plan to return to UTC+00:00 on October 28, 2018. But the data in Africa doesn't change. There still are four clock changes in 2018, which causes isdst flag error in 2019. https://support.microsoft.com/en-us/help/4468323/dst-and-time-zone-changes-… https://www.timeanddate.com/news/time/morocco-abolishes-time-changes.html Before change, [cid:image001.png@01D59979.EB9BDA90] on May 5 2019, the time jumps from 02:59:59 to 02:00:00, the isdst flag should change from 1 to 0. After change, [cid:image002.png@01D59979.EB9BDA90] When dataform is rearguard, it is fixed via ziguard.awk, [cid:image003.png@01D5997A.49F01BB0] However, I don't understand why it's only changed in rearguard format.

2 1

Changes in daylight saving rules in Brazil
by Alexandre Henrique Soares Dias Nov. 6, 2019

Nov. 6, 2019

Dear IANA Team, My name is Alexandre Dias and I'm a Data Scientist at a Brazilian Startup called Looqbox. As an R programmer and knowing that R uses the international standard IANA time zone rules. I would like to inform that the current Brazilian government changed daylight saving rules for "America/Sao_Paulo" timezone. This changes occurred this year and many devices are operating under the wrong hour of the day. Usually, at this time of the year we had to advance our clock by one hour going from -03 GMT to -02. However, as I said, this is no longer the rules and the clocks must remain -03 GMT. Following there is a print of this phenomenon showing that R is display and returning the wrong time for my timezone: [image: image.png] <https://files.slack.com/files-pri/T0NA05E3Y-FQ4LFH6CV/image.png> The correct output should be "2019-11-04 13:25:27 -03". Given the problems that may arise from this kind of behavior, I kindly ask you to apply the changes I informed above as soon as possible. Sincerely yours, Alexandre Henrique Soares Dias Data Scientist at Looqbox

3 2

No more DST in Brazil
by Sergio Leal Nov. 4, 2019

Nov. 4, 2019

Dear Sirs, I am a PHP programmer and I verified a problem when I setted a timezone location to "America/Sao_Paulo" for a program. I observed that data was showing dates and times with 1 hour difference. After some search, I downloaded the TZ database from https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz where I believe that Brazilian DST remains setted, despite of Brazilian Governament has officialy cancelled DST in Brazil as described in the file southamerica finded in the TZ database in lines 946 to 949. I hope I could help. Regards, Sergio Leal Enviado do Email para Windows 10

4 3

61472314_Letter from the Embassy of Ukraine
by Embassy of Ukraine in the USA Nov. 4, 2019

Nov. 4, 2019

2 1

Please add Kaliningrad City (UTC+2)
by westmail24＠yandex.com Nov. 4, 2019

Nov. 4, 2019

Hello, If possible, add please Kaliningrad (Russia), UTC+2 without DST in new "tzdata". (It's Moscow -1 Hour.) Regards, Andrew, Russia.

2 1

Potential problem with Sao_Paulo TZ in tzdata2019c
by Bryan Coleman Nov. 1, 2019

Nov. 1, 2019

It appears there is a bug with the America/Sao_Paulo time zone; specifically, with the 2014-02-15/16 DST change. Not sure the best way to confirm and/or if there is someone that can quickly check/verify. Thoughts? I found this while working with java and noticed it after upgrading from adoptopenjdk version 8u222_b10 to version 8u232_b09. I believe 222 utilizes tzdata2019a while 232 utilizes tzdata2019c. I understand that there are many things that could cause the issue from the code running in java down the stack to the tzdata; however, believe tzdata is the most likely culprit. Any thoughts/ideas of how to track this down? Thank you, Bryan Reference Output: jdk 8.222_b10 2014-02-15 23:59:59 BRST: 1392515999000 2014-02-15 23:00:00 BRST: 1392512400000 2014-02-15 23:00:00 BRT : 1392516000000 2014-02-16 00:00:00 BRST: 1392516000000 2014-02-16 00:00:00 BRT : 1392519600000 jdk 8.232_b09 2014-02-15 23:59:59 BRST: 1392519599000 2014-02-15 23:00:00 BRST: 1392516000000 2014-02-15 23:00:00 BRT : 1392516000000 2014-02-16 00:00:00 BRST: 1392519600000 2014-02-16 00:00:00 BRT : 1392519600000

2 1