- tz - lists.iana.org

2021e Asia/Dushanbe
by Nick Deguillaume May 14, 2022

May 14, 2022

Hello, I am currently developing a C++ time-zone database parser, building on top of Howard Hinnant's work. I am writing thorough checks. One Zone check that I am experimenting with is: *If the FORMAT field contains either a "%s" or a '/' then the RULES field must contain a named rule.* However line 3840 of the asia file in: https://data.iana.org/time-zones/releases/tzdata2021e.tar.gz fails this check, as highlighted in yellow in the table below. # Tajikistan # From Shanks & Pottenger. # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Dushanbe 04:35:12 - LMT 1924 May 2 5:00 - +05 1930 Jun 21 6:00 RussiaAsia +06/+07 1991 Mar 31 2:00s 5:00 1:00 +05/+06 1991 Sep 9 2:00s 05:00 - +05 My guess is that '+05/+06' should be '+05'. I may well be wrong. Could you let me know either way? If you are interested, I have found a few other bits and pieces where the data files are in slight variance with the documentation but are not show-stoppers. Most of these occur in the very early releases. (I am testing every database available on https://data.iana.org/time-zones/releases/) Regards Nick Deguillaume +44 75 2828 6473

3 7

Changes to timezone names
by Ростислав Салабай May 12, 2022

May 12, 2022

Good morning! Since Kyiv became an official spelling of the capital of Ukraine, few years have passed. And people more and more use the new spelling, instead of Kiev. That includes large and small news sites, posts of politicians and most social media feeds (seeing Kiev right now is much more rare than Kyiv). Even Wikipedia and Oxford English Dictionary have changed their spellings to Kyiv too, and large companies like Apple follow along. And actually, using Kiev causes more inconvenience for some people than Kyiv, in things that use tz database, as many are unable to find the right timezone (and this isn't something made up, I've seen lots of complains in forums and GitHub issue requests that Kyiv is missing or spelled wrong). Also, the outgoing war in Ukraine has sped up that process of switching Ukraine to Ukrainian-based things, and not Russian ones. So, in my opinion, it's the perfect time to finally ditch Kiev for good, and start using Kyiv (and so the Europe/Kyiv timezone) as the only name for that beautiful city. Rostyslav

2 1

Updates on Iranian Time Zone (IRDT)
by Mohammad Ali Tofighi May 11, 2022

May 11, 2022

Hi. Recently the Iranian parliament has decided to remove daylight saving from the Iranian time zone, eliminating the one-hour shift in the summer time. Hence, it is always going to be UTC+3:30. *This is not their final decision yet* and there is a final confirmation to be made, but I just wanted to inform you about the update to prepare possible modifications. I'm a software engineer and if we have the update on *tzdata* package as soon as possible, the software companies can adjust themselves accordingly. Please read these official news: https://www.isna.ir/news/1400122419045/ https://www.yjc.news/00Xw0k Regards, Ali Tofighi

6 13

Request to provide .tar.gz tarballs for tzdb
by Kim Davies May 6, 2022

May 6, 2022

Dear colleagues, We’ve been asked by this correspondent to forward this request on to this list. In response to the original request we explained the lzip distribution is largely an amalgam of the gzip distributions, and they indicated they still wanted gzip to be considered specifically to increase “availability for low end systems as lzip isn’t that widely supported”: Subject: Provide .tar.gz tarballs for tzdb Date: Mon, 2 May 2022 13:23:15 +0300 From: "Firas Khalil Khana" <firasuke(a)gmail.com> To: iana(a)iana.org Hey there, I've come to notice that both tzcode and tzdata have .tar.gz tarballs but tzdb only has .tar.lz (lzip) tarballs which isn't a commonly used format. Would it be possible to provide gzipped tarballs for tzdb as well? Thanks! -- Kim Davies VP, IANA Services, ICANN President, PTI

5 5

Changes to the tz database
by Shlomi Sasson May 1, 2022

May 1, 2022

hi, i opened this PR <https://github.com/rogierschouten/tzdata-generate/pull/11> on GitHub and I've been told I need to contact you, and specifically Paul Eggert, to fix it. The fix should replace the Ukrainian city Kiev with the official name Kyiv, put Kiev in the legacy zone and add Kyiv to a new zone (per Rogier Schouten <https://github.com/rogierschouten>) Can u pls help me fix that? -- Shlomi Sasson Engineering Group Manager, Bringg +972-52-4440986

3 4

Prague Astronomical Clock simulation
by Kerry Shetline April 21, 2022

April 21, 2022

While not precisely a timezone topic, I thought a simulation of the Prague Astronomical Clock might be of interest to the readers of this mailing list. I stumbled into this topic a few months ago and I find it fascinating. There aren't too many pieces of machinery that are over 600 years old and still running. Now, of course, it's not still all the original equipment in place today, and there has been a lot of downtime over the centuries as interest waxed and waned over keeping the clock running. Major components of the original clock, however, are still in service today. Having looked at other old astronomical clocks, the one in Prague, in my opinion, beats them all. For something first operational in 1410, it's a very ambitious and clever design that puts a lot of information into view all at once, in an attractive and compelling way: two different ways of counting the hours of the day, phases of the moon, position of the moon and the sun in the sky, sun rise and set times, and sidereal time. One of the things I discovered was Jan Tošovský's simulation of clock, which had some attractive SVG graphics, but a user interface that's a bit out of date and clunky by modern UI standards. I used his graphics as a starting point for my own simulation, which can now be found at https://orloj.org/orloj/. I received a lot of help and advice from Petr Král, the current "clock master", and founder of the Czech Horological Society, about the real, physical clock, its operation and history -- not to mention that he helped make sure my translation to Czech wasn't too far out of whack. By the way, if anyone takes a look at the site who speaks Spanish, French, or German, I'd love to hear about any suggestions for improved translations you might have. I used to do a lot of work in the past to make sure code was internationalizable, but this is my first multi-language Angular web application.

1 0

some problems with tzdata for Simferopol
by Michael H Deckers April 18, 2022

April 18, 2022

In version 2022a of the file "europe", we read for Simferopol: # The _Economist_ (1994-05-28, p 45) reports that central Crimea switched # from Kiev to Moscow time sometime after the January 1994 elections. # Shanks (1999) says "date of change uncertain", but implies that it happened # sometime between the 1994 DST switches. Shanks & Pottenger simply say # 1994-09-25 03:00, but that can't be right. For now, guess it # changed in May. 2:00 C-Eur EE%sT 1994 May # From IATA SSIM (1994/1997), which also says that Kerch is still like Kiev. 3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s 3:00 1:00 MSD 1996 Oct 27 3:00s # IATA SSIM (1997-09) says Crimea switched to EET/EEST. # Assume it happened in March by not changing the clocks. 3:00 Russia MSK/MSD 1997 3:00 - MSK 1997 Mar lastSun 1:00u • The quoted text is inconsistent: The comment says that Simferopol uses Moscow time since 1994 May, but the Zone line "3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s" contradicts it (Moscow had other switching times between summer and winter times). Which is correct? • It is not clear what "IATA SSIM (1994/1997)" actually says. They probably do not specify the switching times expressed with the Zone line "3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s" or do they? • The Zone line "3:00 Russia MSK/MSD 1997" is redundant. Michael Deckers.

2 1

No permanent Maryland DST
by Arthur David Olson April 12, 2022

April 12, 2022

This year's regular session of Maryland's state legislature has ended. House Bill 126, establishing permanent Daylight Saving time (with contingencies) had been approved by the House of Delegates on a 108-24 vote; it was not approved by the Senate. We'll see what (if anything) happens at the national level. @dashdashado

1 0

Re: [tz] Wrong name of timezone
by Pierpaolo Bernardi April 11, 2022

April 11, 2022

Il giorno 25 ottobre 2021, alle ore 16:58, Igor Melnyk via tz <tz(a)iana.org> ha scritto: >But Ukraine has the Ukrainian language and Kiev is in russian language. The correct name of the capital city of Ukraine is Kyiv. Kiev is English language, as every other name in the db, not russian. It is only a coincidence that the English name is more similar to russian than to Ukrainian.

6 5

Timekeeping videos
by Tim Parenti April 5, 2022

April 5, 2022

A pair of time-related videos in my recommendations today, Monday 2022-04-04: At 16:00 BST (+01), Tom Scott published a video called "How does Britain know what time it is?" about the radio time broadcasts from the UK's National Physical Laboratory, which disseminates UTC(NPL). https://www.youtube.com/watch?v=yqciKS_N0K8 Typical of his attention to detail, the wall clock Tom holds continues to tick true to time throughout the entire video, even as it cuts away to interview shots and B-roll. A couple hours later, at 18:00 BST, the British comedy panel quiz show "QI" published a clip of their episode "Rude", originally aired 2020-05-28, in which the panel discusses, among other things, how Denmark hasn't updated its laws to officially use UTC instead of Mean Solar Time. https://www.youtube.com/watch?v=jRMD9LRmRA4 -- Tim Parenti

1 0

[Confirmation] America/Punta_Arenas will keep UTC -3 "indefinitely"
by Juan Correa April 3, 2022

April 3, 2022

Hello everyone: As almost all Continenal Chile just jumped back to UTC -4; I found there was a decree published last Thursday that will keep Magallanes region to UTC -3 "indefinitely" The decree is available at https://www.diariooficial.interior.gob.cl/publicaciones/2022/03/31/43217-B/… ; and it's a modification of Decreto 1286/2018 Its only paragraph say: "Nevertheless the aforementioned, the change of the Chile Continental Official time for Magallanes and Antártica Chile region will be extended indefinitely; and will be permanently set to GMT (sic) -3" -- Juan Correa Poblete PS Labs (http://www.pslabs.cl)

2 1

zone file format very strict
by Alois Treindl April 1, 2022

April 1, 2022

Hi I noticed that the last line of a zone file like # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Kabul 4:36:48 - LMT 1890 4:00 - +04 1945 4:30 - +0430 does not suffer a trailing TAB character, behind the +0430 I think the zone file compiling mechanism could be a bit more tolerant of trailing white space. The issue came about because I employ a zone file generator utility, which accidentally created such trailing tabs in some cases. I fixed my generator, but wanted to mention this anyway.

2 2

TZDB talk tomorrow at LibrePlanet 2022
by Paul Eggert April 1, 2022

April 1, 2022

Tomorrow, March 19, at 21:15–22:00 UTC (17:15–18:00 US Eastern time) I plan to deliver a talk "TZDB and some challenges of long data" at the all-online LibrePlanet 2022 conference. LibrePlanet is a conference about software freedom, happening on March 19–20, 2022. The event is hosted by the Free Software Foundation, and brings together software developers, law and policy experts, activists, students, and computer users to learn skills, celebrate free software accomplishments, and face upcoming challenges. Newcomers are welcome, and LibrePlanet 2022 will feature programming for all ages and experience levels. You can register for the conference in advance at <https://my.fsf.org/civicrm/event/info?reset=1&id=99>.

6 6

Some typo fixes
by Sascha Wildner March 31, 2022

March 31, 2022

Hi, please consider the attached patch which fixes three of typos in the tz files. Best regards Sascha Wildner

3 3

indentation in localtime.c
by Roland Illig March 31, 2022

March 31, 2022

Hi, I had a look at tzcode/localtime.c today, and the indentation looks like a mess. It's a wild mixture between 2 spaces, 4 spaces, 1 tab, 2 tabs, and I couldn't see any pattern or reasonable rule set that would account for the whole file. Is this apparent mess intentional? If so, what is the history and rationale behind it? If not, who can fix this? Roland

5 4

Regarding time zone changes in Chile
by Juan Correa March 31, 2022

March 31, 2022

Hello everyone: A few days ago, I've seen some mails regarding time zone changes, specially regarding Punta Arenas. I found https://www.horaoficial.cl/historia_hora.php ; a page (with a terrible slider) with more details regarding time zones in Chile What comes for bringing this page is for 2 points, brought by Alois Treindl a few weeks ago: - From January 10, 1910, the Official Time Zone for all of Chile was set to GMT -5. I've got to check through the exact wording, but it's important to keep track that legally, all Chile has an uniform common time zone (that, obviously, started to change from 1916). - On August 22, 1927, DST was established as "hora oficial de invierno" and "hora oficial de verano"; jumping from a relative time zone from Lo Espejo observatory (-4:42:46) to UTC -5 during winter (and GMT -4 during summer). As there's a decree establishing that, I will request it to share; but using the same principle, the time zone for all of Chile was standardized using those 2 time zones (until further notice) In other matters, I've repeatedly contacted the Ministry of Energy (as Tim could see ;) ) by Twitter, through their Information Office and now by telephone, regarding America/Punta_Arenas this saturday. What they just told me is they have to check the interpretation of the decree (…), as it says "permanently", but seems everyone skipped the date before that word. I've also checked Diario Oficial (our legislation gazette) from March 1; and there is no decree yet. I will try other ways to get as soon as possible that information. However, vox populi, everyone is assuming Punta Arenas (and Magallanes) will keep UTC -3; so I think it was a sensible assumption back in the day -- Juan Correa Poblete PS Labs (http://www.pslabs.cl)

1 0

America/Dawson_Creek
by Michael Ewert March 28, 2022

March 28, 2022

Hello. TZ is a great database for all the different clocks in the world, and their changes. Thank-you for researching and maintaining such a great resource. America/Dawson_Creek has coordinates listed as +5946-12014, however I believe that the intended coordinates are +5546-12014. Thank-you for your work keeping the world ticking. Michael Ewert

2 1

Time zone in the news
by Arthur David Olson March 27, 2022

March 27, 2022

'Autocorrect in @washingtonpost <https://twitter.com/washingtonpost/>: "Gare de l'Est" becomes "Gare de l'Eastern time." Article by @Claremch <https://twitter.com/Claremch/>, "How Russian emigres scratched out a living once they lost their world of riches." Also an editing lapse of course, and no, I couldn't find this article online.' https://twitter.com/Seth4MC/status/1508059818598219777 (Not-so-fun fact: in one round of C language standardization, it took months of repeated effort to get "time zone name" changed to "time zone name or abbreviation.") @dashdashado

2 1

Maryland permanent DST hearing
by Arthur David Olson March 24, 2022

March 24, 2022

A Maryland State Senate committee hearing covering (among other things) a Maryland-specific permanent Daylight Saving Time bill is set to begin at 1:00 USEDT. The link... https://www.youtube.com/channel/UCYqghFoT_BDQ0N5xjvTacgg/videos ...will get you to the Youtube channel where the hearing should be viewable. @dashdashado

2 2

Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone
by heba.hamad＠mtit.gov.ps March 24, 2022

March 24, 2022

Dear Sir, kindly find the attachment below that includes the response of your comments about the first part of Palestines specification Time Zone BR,في الاثنين, يناير 24, 2022 05:15 EST, "Clive D.W. Feather" <clive(a)davros.org> كتب: Heba Hamad via tz said: > Dear Sir, > > Hope this email finds you well and wishing you a joyful new year . > We would like to inform you that The State of Palestine has adopted the > first part of the specification for its time zone. > Kindly refer to the attachment below, which includes the specification > and please provide me with any comments or notes you have regarding > this specification. > Ps: Please provide me with any comments you have. > Sincerely Yours, > > Eng.Heba Hamad Dear Mr Hamad, My apologies for the length of time this reply has taken, but here are some comments on your document. Page 6 item 2: the second paragraph looks more like a definition of local time than of UTC. Compare with item 6 on the next page. Page 7 item 7: while this is the commonest form of "daylight saving time" or "summer time", as it is usually known in Europe, it is not the only possibility: * Some countries have two switches forward and two back per year, for example to move back to standard time for Ramadan then forward for the rest of the summer. * At least historically, some places have had two forward shifts at different points in spring and then two backwards shifts at different point in the autumn. * Not all shifts are an hour: Lord Howe Island in Australia has a shift of 30 minutes forward in the summer. * At least one country defines "standard time" as being the time in the summer, with a shift back to "winter time" in autumn and then forward to standard time in spring. * There is at least one historical record where an area put the clocks forward in winter because of an unusual geography. You might at least want to delete the words "one hour from standard time". Page 8: note 1 to entry contradicts the definitions. Item 6 on page 7 implies that "standard time" is a fixed offset from UTC whereas this implies it isn't. Page 9 item 1: the range of dates under consideration affects time zones. The IANA database normally only looks at the situation from 1970 onwards. Picking other starting dates will affect which time zones exist because places differed in time before 1970 but not after it. This is why the IANA database has both Asia/Gaza and Asia/Hebron. Page 9 item 4: this is a description of the IANA TZ database. It is possible for other TZ databases to exist and they might not match that defintion. Also note that updates can be for changes made other than by political bodies (the IANA TZ database works on what actually happens on the ground, not what politicians say what happens). Page 10 item 5: "Government is expected to select these names alone" is, I'm afraid, false. Each database owner selects these names. The IANA database normally uses names of the form "continent/city" or "continent/region/city", but another database might use simple numbers or randomly allocated four-letter strings instead. Page 10 item 6: the description doesn't bear any relationship to the Palestinian Government. Page 11 first line: is the text beginning "This specification" meant to be the start of a new item? It doesn't seem to have anything to do with "Observance". Page 11 item 1: I'm not clear what the purpose of this item is. Page 11 item 2: the first paragraph describes the IANA TZ database rules and other TZ databases may differ. The last sentence of the second paragraph is not true, I'm afraid, since each TZ author can pick their own values and accept registrations or other information from anyone. I suspect you may have got your concepts confused. May I please suggest alternative wording? ==== BEGIN ==== The Structure: 1. Palestine Time Zone Palestine will use a single time zone. The State of Palestine is the Palestine Time Zone owner. It has the sole right to determine: - the UTC offset for the zone - the rules for changing this offset at different times of the year - the names and abbreviations used for the time in Palestine in official Palestinian documents. Note: before 2013 Palestine had two time zones using the meaning under "Fundamental Principles". Therefore some distributions may continue to use two time zones in order to represent pre-2013 data. 2. Names and abbreviations Palestine will use the terms and abbreviations "Palestine Standard Time (PSST)" for the time in Palestine during standard time and "Palestine Daylight Time (PSDT)" for the time in Palestine during Daylight Savings. ==== END ==== Legal clause: you of course have the right to determine the name used in official Palestinian documents and the official time used in Palestine. But you cannot determine the name of the time zone in any given database because that's decided by the database owner. Note, here, the difference between your official names (e.g. "PSST"), which you ahve the exclusive right to decide, and names used by others (e.g. "Asia/Gaza" or "A261"), which you don't. Yours sincerely, Clive D.W. Feather -- Clive D.W. Feather | If you lie to the compiler, Email: clive(a)davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

2 1

Re: [tz] Unexpected last transition in Africa/Casablanca
by Kerry Shetline March 23, 2022

March 23, 2022

This image might make the issue clearer: https://i.imgur.com/6PFLDeWh.png What happened is that what used to be called DST is now considered the standard time for this timezone, and what used to be standard time is now *negative* DST. > Here are the last transitions in Africa/Casablanca output (rearguard > format): > > transition,type,[UTC time],[Type offset],[Type isDST] > 3672612000,1,2086-05-19T02:00:00Z,PT1H,DST > 3699828000,2,2087-03-30T02:00:00Z,PT0S,STD > 3703456800,3,2087-05-11T02:00:00Z,PT1H,STD > > So change is from standard to standard, even though offset changes from 0h > to 1h. Is that expected behaviour?

2 1

zic man page vs RFC8536
by Almaz Mingaleev March 22, 2022

March 22, 2022

Man page says that AT can be "260:00" [1]. Though in the RFC hour part in the footer is in [-167, 167] range [2]. Is man page information correct / safe to use? Thanks, Almaz [1] https://github.com/eggert/tz/blob/64c5d196f739b7662497b0986d4d94c418a3fd85/… [2] https://datatracker.ietf.org/doc/html/rfc8536#section-3.3.1

2 1

Announcing global-tz - 2022ag (beta)
by Stephen Colebourne March 21, 2022

March 21, 2022

As regular readers of this list will be aware, there is a long-running dispute about the contents of the IANA time-zone database. (See the list history for details on the dispute). As previously discussed, and given the unwillingness of the tz-coordinator to alter his opinion in any way, it is unfortunately the case that a fork of tzdb is required. I have created such a fork, one that is intended to be as directly derivable from iana-tz as possible so that iana-tz itself can still be the golden source for the raw data. https://github.com/JodaOrg/global-tz The basic rules guiding the data that global-tz includes are: * An identifier for each region of the world where clocks have differed since 1970-01-01. * At least one identifier for each inhabited ISO 3166-1 code. * For these identifiers the data returned shall be the best available, including pre-1970 history. The first release of the fork is 2022ag-beta1, which will become the final 2022ag release tomorrow if there are no major issues or objections. https://github.com/JodaOrg/global-tz/releases/tag/2022ag-beta1 The approach taken is to copy data from backzone and put it back into the main files. This recreates tzdb as it would have been had the damaging changes since 2014 not been made. The process is *automated*. A GitHub Action script runs a few times a day that reads the iana-tz repo and runs a script that moves data from backzone to the appropriate main file. The result is an iana-tz compatible source code repo: Output tzdb source files: https://github.com/JodaOrg/global-tz/tree/global-tz Comparison between iana-tz and global-tz: https://github.com/JodaOrg/global-tz/compare/iana-tz...global-tz Genaration script: https://github.com/JodaOrg/global-tz/blob/main/actions.txt https://github.com/JodaOrg/global-tz/blob/main/GlobalTzMain.java The only maintenance that the fork should need is if iana-tz removes further pre-1970 history. Downstream consumers should be able to take the generated source code (either from the global-tz branch or the released tar.gz file) and consume it as they would have consumed an iana-tz release. Joda-Time and threeTen-Backport will be using global-tz going forward. Please can I ask anyone that is interested to test out the 2022ag-beta1 release before I make it final. PRs / Issues are welcome, provided they relate to aspects under the control of global-tz. thanks Stephen

7 13

Re: [tz] Review incorrect man-pages commit
by Alejandro Colomar (man-pages) March 20, 2022

March 20, 2022

Hi, Branden! On 3/20/22 11:52, G. Branden Robinson wrote: > > Sure! The punctuation does get a bit bewildering. > [...] Thanks for the great explanation! > > Now, for the part people actually care about, which is how to fix it: > take the escape character off of that `. > > You thus want > > +to "\fI[a\('a\(`a\(:a\(^a]\fP", that is, I applied a patch with this. > > If you wanted to write this without using any aliases, you could adopt > groff syntax. > > +to "\fI[a\[a aa]\[a ga]\[a ad]\[a a^]\fP", that is, I'm going to hold this for later, so that we decide globally how to format all pages, and not just this one. I prefer global consistency here. > > I don't know if people regard that as more or less impenetrable. It is > more _flexible_, and admits usage of diacritics/combining characters not > envisioned by AT&T troff or ISO Latin-1. groff supports a baker's > dozen. They are in a table titled "Accents" in groff_char(7) (1.22.4). > >> diff --git a/man8/zic.8 b/man8/zic.8 >> index 940d6e814..aeca0e726 100644 >> --- a/man8/zic.8 >> +++ b/man8/zic.8 >> @@ -293,7 +293,7 @@ nor >> .q + . >> To allow for future extensions, >> an unquoted name should not contain characters from the set >> -.q !$%&'()*,/:;<=>?@[\e]^`{|}\(ti . >> +.q !$%&'()*,/:;<=>?@[\e]^\`{|}\(ti . > > You didn't proffer any complaints about the foregoing, so I assume it > was just for context (to include the whole commit, maybe). Yep > Nevertheless I think it can be further improved. > > That neutral apostrophe and caret/circumflex should be changed as well, > to ensure that they don't render as a directional closing (right) single > quote, ’ U+2019 and modifier letter circumflex ˆ U+02C6. This advice is > also in groff 1.22.4's groff_man(7) page. > > +.q !$%&\(aq()*,/:;<=>?@[\e]\(ha\`{|}\(ti . > > Moreover, as partly noted in our discussion about double quotes in macro > arguments, there were no special characters for the double quote or > neutral apostrophe in Unix troff. Since we're not getting 50 years of > backward compatibility anyway, for the Linux man-pages project I > recommend going ahead and using groff-style escape sequences for these. > > +.q !$%&\[aq]()*,/:;<=>?@[\[rs]]\[ha]\`{|}\[ti] . > > Are you willing to settle for 30 years of backward compatibility? ;-) I do :) However, I'm not going to fix this page, according to MAINTAINER_NOTES: $ cat MAINTAINER_NOTES Externally generated pages ========================== A few pages come from external sources. Fixes to the pages should really go to the upstream source. tzfile(5), zdump(8), and zic(8) come from the tz project (https://www.iana.org/time-zones) bpf-helpers(7) is autogenerated from the kernel sources using scripts. See man-pages commit 53666f6c30451cde022f65d35a8d448f5a7132ba for details. So now I wonder why this commit was written in the first place, since it breaks one page, and fixes another that shouldn't be fixed. I CCd the tz mailing list in case they want to fix the upstream page (which I couldn't find, BTW). > > In my opinion it is more helpful in dense contexts like this to have the > paired delimiters [ ] to demarcate the glyph identifier then to achieve > portability to systems that don't support identifiers you need anyway. Yes, I agree with that. > > (I note that `q` is a page-local macro and therefore bad style for > portability reasons. That said, I have been _sorely_ tempted to add a > `Q` macro for this precise purpose to groff man(7). I have hopes that > it would give people something to reach for besides bold and italics for > every damn thing.) > > Most--I hope all--of the above is discussed comprehensively in the > current version of groff_char(7)[2], which I have rewritten completely > since groff 1.22.4 and substantially modified even since the last Linux > man-pages snapshot at > <https://man7.org/linux/man-pages/man7/groff_char.7.html>. I now know > the answers to many questions of the form "why the **** is {groff,troff} > this way?", and have endeavored to share them. The "History" section is > completely new. > > Regards, > Branden > > [1] groff's own man pages are not without sin in this regard. I have > cleaned them up a lot since 1.22.4, but a few adventurous stragglers > remain that define and use page-local macros pervasively. All are > on the long side. > > [2] https://git.savannah.gnu.org/cgit/groff.git/tree/man/groff_char.7.man > > I recommend that for source perusal only; do not try to render it > with man-db man(1) or groff 1.22.4, because groff 1.23.0 will be > adding a new macro, `MR`, for man page cross references[3] and its > own pages have already been ported to use it. (This is where I > flagellate myself for not having a groff 1.23.0-rc2 out yet. :( ) > > [3] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n165 I like your references usually containing other references themselves. It's funny :-) Cheers, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/

1 0

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson March 18, 2022

March 18, 2022

I do not think we have handled this well; we have not given Victor Perov a good answer. Indeed, to some extent we've made it a "runaround." We can do better. We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets peopl. Victor Perev: I don't have time for a full write-up right now, but please consult the archives of the tz list (http://mm.icann.org/pipermail/tz/ or perhaps https://www.google.com/search?q=site%3Amm.icann.org%2Fpipermail%2Ftz%2F+kyiv which returns 203 results). The tz project is very conservative in its judgment for when the predominant English spelling of a city has changed, and so far the project has judged that Kiev is still preferred. We discussed it when major English newspapers and style guides changed from Kiev to Kyiv last year (prompted by the US presidential impeachment, which lead to a lot of discussion about Kyiv in America), and we will probably continue to discuss it as time goes on. But we've thought about it and discussed it a lot. The answers you got don't explain that, and that means we have not done a good a job as we should have. Sorry about that. In particular, I think Brian Inglis's answer was actually incorrect in a way that really matters ("Kiev is the correct English spelling"). There are multiple correct English spellings. It used to be that Kiev was the only one, but Kyiv is gaining popularity more and more. Paul Eggert <eggert(a)cs.ucla.edu> wrote on Sat, 15 Aug 2020 at 18:19:08 EDT in <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu>: > Thanks for bringing that to the mailing list (if I could shut off GitHub > pull requests I would). Although you cannot do so, we can handle them a little bit better. Please see https://docs.github.com/en/github/building-a-strong-community/creating-a-pu… You can create a template that explains to a would-be pull request submitter than pull requests will be closed and the project uses the mailing list for development discussions. ("I understand that the tz project does not use pull requests on github, and that if I enter a pull request here, it will be closed and I will be directed to send email to tz(a)iana.org.") For the particular case of regular, recurring issues, it may be worth while to keep one of #15, #26, and #27 open and mark the others as a duplicate of it, so that it is easier for newcomers to understand that this issue has been carefully considered and is not a simple oversight. https://github.com/eggert/tz/pulls?q=kiev Also, not to pick on Brian (again), but if the project policy is not to use github pull requests, it's not great to respond to pull requests on their substance, because it bifurcates the discussion and makes it seem like we actually do use pull requests ("except when we don't"). So what seems like a helpful thing may not be. -- jhawk(a)alum.mit.edu John Hawkinson

10 13