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. 7, 2019

Dec. 7, 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. 3, 2019

Dec. 3, 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. 2, 2019

Dec. 2, 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. 23, 2019

Nov. 23, 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. 23, 2019

Nov. 23, 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