- tz - lists.iana.org

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