- tz - lists.iana.org

Request for Standardization of Kyiv Time Zone Naming
by Dmytro Shynkarenko Nov. 11, 2023

Nov. 11, 2023

Dear IANA Team, I'm reaching out on behalf of our team at Tutorpeers (Tutorpeers.com) I'm reaching out to address a significant concern related to the naming of Ukraine's capital in time zone databases. At present, there are two spellings in use: "Kiev" and "Kyiv." The latter, "Kyiv," is the correct Ukrainian spelling and pronunciation, which honors the country's sovereignty and the preferences of its people. The use of "Kiev," which is derived from the Russian language, has become increasingly problematic, especially considering Russia's ongoing aggression against Ukraine. This issue hits close to home for me, not only because of my Ukrainian roots but also due to the feedback we've received from our Ukrainian user base. Numerous customers have reached out to us, expressing discomfort and disapproval of the "Kiev" spelling, given the current circumstances. Our platform has taken a clear stance on this issue, and we urge IANA to consider the implications of language and to update its time zone databases accordingly. By standardizing the "Kyiv" spelling, we can collectively show support for the Ukrainian community and respect their cultural and national identity. After speaking to your colleague Candice Montoya I was pleased to learn that the spelling change to "Europe/Kyiv" has already been implemented in the Time Zone Database as of August 2022. This update is much appreciated and reflects a positive and respectful acknowledgment of the correct naming convention. However, I've noticed that the previous spelling, "Kiev" still appears in some instances. Please confirm if this is intended for backward compatibility with existing systems. And if so, is there a planned timeline for its eventual deprecation in favor of the updated "Kyiv" spelling? Understanding the strategy for phasing out the old spelling would be incredibly helpful for our team and user community as we navigate these changes and ensure we provide the most current and accurate information. Thank you once again for your attention to this matter. Regards, Dmytro Project Coordinator at Tutorpeers

4 3

Error for Chile on September 2023
by Jacqueline Seron Nov. 7, 2023

Nov. 7, 2023

Hello On September 2023, Chile changed the date for DST from September 3rd to September 11th. I do not see this change in the database. See the government webpage that indicated this change https://horaoficial.cl/CambioHusoHorario.php Thank you -- Jacqueline Seron N. NOIRLab - AURA

8 16

[PROPOSED] Update AASM citation to 2023
by Paul Eggert Nov. 1, 2023

Nov. 1, 2023

* tz-link.html (Costs and benefits of time shifts): Link to 2023 edition of the American Academy of Sleep Medicine position statement. --- tz-link.html | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/tz-link.html b/tz-link.html index 19740b11..a29231d5 100644 --- a/tz-link.html +++ b/tz-link.html @@ -998,13 +998,15 @@ standard time in the United States: a Sleep Research Society position statement. doi:<a href="https://doi.org/10.1093/sleep/zsac236">10.1093/sleep/zsac236</a>. After reviewing of the scientific literature, the Sleep Research Society advocates permanent standard time due to its health benefits. -<li>Rishi MA, Ahmed O, Barrantes Perez JH et al. -<a href="https://jcsm.aasm.org/doi/10.5664/jcsm.8780">Daylight saving time: +<li>Rishi MA, Cheng JY, Strang AR et al. +<a href="https://jcsm.aasm.org/doi/10.5664/jcsm.10898">Permanent standard time +is the optimal choice for health and safety: an American Academy of Sleep Medicine position statement</a>. -J Clin Sleep Med. 2020;16(10):1781–1784. -doi:<a href="https://doi.org/10.5664/jcsm.8780">10.5664/jcsm.8780</a>. -This argues for permanent standard time due to health risks of both -<abbr>DST</abbr> transitions and permanent <abbr>DST</abbr>.</li> +J Clin Sleep Med. 2023-10-31. +doi:<a href="https://doi.org/10.5664/jcsm.10898">10.5664/jcsm.10898</a>. +This argues for permanent standard time due to health and safety risks +and economic costs of both <abbr>DST</abbr> transitions and +permanent <abbr>DST</abbr>.</li> <li>Roenneberg T, Wirz-Justice A, Skene DJ et al. <a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7205184/">Why should we abolish Daylight Saving Time?</a> -- 2.41.0

1 0

[PROPOSED] Ittoqqortoormiit (America/Scoresbysund) zone change
by Paul Eggert Oct. 29, 2023

Oct. 29, 2023

* NEWS: Mention this. * europe (America/Scoresbysund): Switch to -02/-01 on 2024-03-31. --- NEWS | 8 ++++++++ europe | 14 +++++++++++++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 9a085948..e5ead4cf 100644 --- a/NEWS +++ b/NEWS @@ -3,10 +3,18 @@ News for the tz database Unreleased, experimental changes Briefly: + Ittoqqortoormiit, Greenland changes time zones on 2024-03-31. Code and data fixes for Palestine timestamps starting in 2072. Changes to future timestamps + Ittoqqortoormiit, Greenland (America/Scoresbysund) joins most of + the rest of Greenland's timekeeping practice on 2024-03-31, by + changing its time zone from -01/+00 to -02/-01 at the same moment + as the spring-forward transition. Its clocks will therefore not + spring forward as previously scheduled. The time zone change + reverts to its common practice before 1981. + Fix predictions for DST transitions in Palestine in 2072-2075, correcting a typo introduced in 2023a. diff --git a/europe b/europe index 012d1498..6e59f62d 100644 --- a/europe +++ b/europe @@ -1130,6 +1130,17 @@ Zone Atlantic/Faroe -0:27:04 - LMT 1908 Jan 11 # Tórshavn # However, Greenland will change to Daylight Saving Time again in 2024 # and onwards. +# From an contributor who wishes to remain anonymous for now (2023-10-29): +# https://www.dr.dk/nyheder/seneste/i-nat-skal-uret-stilles-en-time-tilbage-m… +# with a link to that page: +# https://naalakkersuisut.gl/Nyheder/2023/10/2710_sommertid +# ... Ittoqqortoormiit joins the time of Nuuk at March 2024. +# What would mean that America/Scoresbysund would either be in -01 year round +# or in -02/-01 like America/Nuuk, but no longer in -01/+00. +# +# From Paul Eggert (2023-10-29): +# For now, assume it will be like America/Nuuk. + # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Thule 1991 1992 - Mar lastSun 2:00 1:00 D Rule Thule 1991 1992 - Sep lastSun 2:00 0 S @@ -1149,7 +1160,8 @@ Zone America/Danmarkshavn -1:14:40 - LMT 1916 Jul 28 Zone America/Scoresbysund -1:27:52 - LMT 1916 Jul 28 # Ittoqqortoormiit -2:00 - -02 1980 Apr 6 2:00 -2:00 C-Eur -02/-01 1981 Mar 29 - -1:00 EU -01/+00 + -1:00 EU -01/+00 2024 Mar 31 + -2:00 EU -02/-01 Zone America/Nuuk -3:26:56 - LMT 1916 Jul 28 # Godthåb -3:00 - -03 1980 Apr 6 2:00 -3:00 EU -03/-02 2023 Mar 26 1:00u -- 2.39.2

2 2

Y2K & T2G in the news
by Arthur David Olson Oct. 29, 2023

Oct. 29, 2023

"Y2K bug was real and could have killed says man who found it — here’s when it could hit again" https://nypost.com/2023/10/28/lifestyle/y2k-bug-could-have-killed-heres-whe… @dashdashado

1 0

UNIX epoch on X/Twitter
by Arthur David Olson Oct. 26, 2023

Oct. 26, 2023

A presumably unintended appearance: https://twitter.com/Seth4MC/status/1717535728958062678 @dashdashado

1 0

Invalid POSIX TZ strings in generated TZif files
by Jacob Pratt Oct. 26, 2023

Oct. 26, 2023

The format for POSIX TZ strings is defined here: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#ta… I will note two things from this specification: - The hour shall be between zero and 24 - The *time* has the same format as *offset* except that no leading sign ( '-' or '+' ) is allowed There are four time zones that violate these requirements. - Asia/Gaza has DST transitions that occur 50 hours after midnight (both start and end). - Likewise for Asia/Hebron. - Asia/Jerusalem has a DST transition that begins 26 hours after midnight. - America/Nuuk has a DST transition that begins -1 hours after midnight (not a typo). Violating the first requirement is unspecified behavior, and violating the second is simply not allowed. I ran across these situations while testing a parser for TZif files that I wrote. While the desired behavior is clear, it is also the case that Gaza, Hebron, and Jerusalem rely on unspecified behavior and Nuuk should never parse successfully. Both of these are far from ideal, of course. I'm not entirely certain what can be done here, as the POSIX format is incapable of handling situations like this at first glance. Jacob Pratt

3 3

Re: [tz] Electric Pressure Cooker&Induction Cooker Distributor Needed
by alan＠zsalan.com Oct. 23, 2023

Oct. 23, 2023

1 0

Hard copy of TZdata2023?
by natyaveda Oct. 22, 2023

Oct. 22, 2023

Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form? Perhaps this has been produced by someone in the astrology community? I'm basically looking to see if its possible to get the rights to include parts of such a publication in a publication of my own. I doubt one exists that includes all the info for every city in the world in a single publication, but I'm looking to see if it does and how large it might be. What I have in mind is something that lists information pretty much exactly as its presented in the tables for the "Detailed time zone and clock changes" available on timeanddate.com (minus everything outside the tables): https://www.timeanddate.com/time/zone/canada/vancouver Thanks for any info you can provide! -James Foyle

8 19

[man]: Bullet lists
by Alejandro Colomar Oct. 22, 2023

Oct. 22, 2023

Hi Paul, I have a small suggestion for formatting of manual pages. Recently, I made lists uniform in the Linux man-pages project, and set some rules for them. See man-pages(7): Lists There are different kinds of lists: ... Bullet lists Elements are preceded by bullet symbols (\[bu]). Anything that doesn’t fit elsewhere is usually covered by this type of list. ... There should always be exactly 2 spaces between the list symbol and the elements. This doesn’t apply to "tagged paragraphs", which use the de‐ fault indentation rules. I guess using '\[bu]' (or '\(bu') might not be appropriate for the tz project, as it may be less portable to old systems, but the 2 spaces between the bullet (the '*' in your case) and the text would be useful. It better distinguishes text from bullets, in the few cases where it may be ambiguous (I didn't check if any may be ambiguous in the tz project). The change would be to use '.IP * 3' instead of '.IP * 2'. 3 is for the width of '*' +2. Would you be interested in such a change? Thanks, Alex -- <https://www.alejandro-colomar.es/>

2 3