- tz - lists.iana.org

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

Unfortunate time zone names in the United States
by John Levine March 18, 2022

March 18, 2022

Here's the soon to be screwed up definition of US time zones. 15 USC 261 says For the purpose of establishing the standard time of the United States, the territory of the United States shall be divided into nine zones in the manner provided in this section. Except as provided in section 260a(a) of this title, the standard time of the first zone shall be Coordinated Universal Time retarded by 4 hours; that of the second zone retarded by 5 hours; that of the third zone retarded by 6 hours; that of the fourth zone retarded by 7 hours; that of the fifth zone retarded 8 hours; that of the sixth zone retarded by 9 hours; that of the seventh zone retarded by 10 hours; that of the eighth zone retarded by 11 hours; and that of the ninth zone shall be Coordinated Universal Time advanced by 10 hours. 15 USC 263 says: The standard time of the first zone shall be known and designated as Atlantic standard time; that of the second zone shall be known and designated as eastern standard time; that of the third zone shall be known and designated as central standard time; that of the fourth zone shall be known and designated as mountain standard time; that of the fifth zone shall be known and designated as Pacific standard time; that of the sixth zone shall be known and designated as Alaska standard time; that of the seventh zone shall be known and designated as Hawaii-Aleutian standard time; that of the eighth zone shall be known and designated as Samoa standard time; and that of the ninth zone shall be known as Chamorro standard time. Section 260a currently has the daylight saving rule, advance in March, fall back in November. The bill passed by the Senate deletes 260a, and updates 261 to change each of the numbers by an hour, 4 changes to 3, 5 to 4, and so forth 11 changes to 10 and the final 10 changes to 11. But it does *not* change section 263. This means that the official US names of the time zones change, which is really stupid. Since Hawaii, Samoa, and Guam do not use daylight time, Hawaii will now be in Alaska standard time, Samoa in Hawaii-Aleutian standard time, and Guam in a time zone with no name. I hope the House will fix this if they take up the bill, but I wouldn't make any changes to my time zone files yet. With respect to Canada, history shows that their timezones follow the US so if the US make a change like this, a bill in Ottawa will change Canada to match. There are currently places where you change time when you cross the border, like between Maine and New Brunswick, but it would be too painful for Montreal and Toronto and Windsor not to match New York and Detroit, and Vancouver not to match Seattle. R's, John

8 12

permanent DST and North American time zone names
by Chris Walton March 18, 2022

March 18, 2022

Regardless of what the legislation does or does not say, this database needs to quickly adopt a strategy to deal with changes that may be necessary for all North American Time zones. The supporters and maintainers of this time zone database can take an active role in helping to define and endorse a common standard, or they can sit back and watch the politicians and the general public fumble the job. It would be helpful if there was some collaboration between Microsoft and the supporters/maintainers of this database. I think it is likely that if the US government approves the Sunshine Protection Act, that most Canadian provinces and territories will follow with similar legislation. - British Columbia and Ontario already have the necessary legislation in place. - Saskatchewan has not changed its clocks in many years. - Yukon stopped changing its clocks in 2020. - Alberta recently voted to keep the biannual change, it could be the lone holdout! I admit I have not been following the other Canadian territories and provinces closely. Also, I have no clue what Mexico, Saint Pierre & Miquelon, or any of the small island nations will decide to do. For this database I can envision four options moving forward: *Option #1*: ditch the three letter time zone strings and use only numerical offsets from UTC. This is a complete cop out that says "Let's abandon our end users and let somebody else deal with the issue". It is my least favorite option. e.g. Los Angeles, Phoenix, and Vancouver: Thu Feb 1 00:00:00 *-07* 2024 (UTC-07) Thu Aug 1 00:00:00 *-07* 2024 (UTC-07) e.g. New York and Toronto: Thu Feb 1 00:00:00 *-04* 2024 (UTC-04) Thu Aug 1 00:00:00 *-04* 2024 (UTC-04) *Option #2*: allow permanent daylight saving This could be implemented without too many complications, but it goes against the philosophy that daylight saving is an alternate time offset that is only used for part of the year. This is not my favorite option even though it is probably the least disruptive. I do not think it will make any sense 20 years from now. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Pacific Daylight Time* Thu Feb 1 00:00:00 *PDT* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Eastern Daylight Time*: Thu Feb 1 00:00:00 *EDT *2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-04) *Option #3*: move most North American entries in the TZ database one zone to the east: I know we have done this in the past for places such as America/Whitehorse, but I expect if we did it for all of Canada and the US it would not align with the public's perception of reality. Also, it provides no clear path to deal with any places that are currently using *Atlantic Daylight Time (UTC-03)*. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Mountain Standard Time* Thu Feb 1 00:00:00 *MST* 2024 (UTC-07) Thu Aug 1 00:00:00 *MST* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Atlantic Standard Time*: Thu Feb 1 00:00:00 *AST* 2024 (UTC-04) Thu Aug 1 00:00:00 *AST* 2024 (UTC-04) *Option #4*: redefine AKST, PST, MST, CST, EST, AST, and NST to all be one hour closer to UTC time. This is currently my preferred option even though it may break some software and it is guaranteed to conflict with the Canadian Interpretation Act. Alaska Standard Time (AKST) is redefined to UTC-08. Pacific Standard Time (PST) is redefined to UTC-07. Mountain Standard Time (MST) is redefined to UTC-06. Central Standard Time (CST) is redefined to UTC-05. Eastern Standard Time (EST) is redefined to UTC-04. Atlantic Standard Time (AST) is redefined to UTC-03. Newfoundland Standard Time (NST) is redefined to UTC-02:30 (assuming Newfoundland abandons the biannual time change) e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on *Pacific Standard Time* year-round: Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PST* 2024 (UTC-07) e.g. New York and Toronto would be on *Eastern Standard Time* year-round: Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. Alberta would have to adopt new time zone names: *Pacific Standard Time* in winter, and *Pacific Daylight Time* in summer. (Alberta recently voted to keep the biannual clock change). Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-06) e.g. Saskatchewan would have to start referring to its time zone name as *Mountain Standard Time* instead of *Central Standard Time*. (Saskatchewan has used *UTC-06* year-round for many years) Thu Feb 1 00:00:00 *MST* 2024 (UTC-06) Thu Aug 1 00:00:00 *MST* 2024 (UTC-06) e.g. Puerto Rico would have to start referring to its time zone as *Eastern Standard Time* instead of *Atlantic Standard Time*. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. If Atlantic Canada and Bermuda were to continue changing the clocks twice a year, they would be on *Eastern Standard Time* in winter and *Eastern Daylight Time* in summer. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-03) e.g. If, Atlantic Canada and Bermuda were to abandon the time change, then they would both end up on *Atlantic Standard Time* year-round. Thu Feb 1 00:00:00 *AST* 2024 (UTC-03) Thu Aug 1 00:00:00 *AST* 2024 (UTC-03) Did I miss anything? -chris

13 17

Iran DST change cancelled and step to avoid DST changing in their Linux system
by S Sathish S March 18, 2022

March 18, 2022

Hi Team, Customer running with Asia/Tehran (+0330, +0330) timezone, where Daylight saying is cancelled by their Iran government recently. Our Operator are requesting to avoid DST changing in their Linux system and expect tzdata patch from IANA (or) if possible any workaround to avoid this DST change in their systems. Thanks and Regards, S Sathish S

3 4

tzData Update for Iran DST
by Jahar Tyagi March 17, 2022

March 17, 2022

Hi, Recently learned that Iran has decided to stop DST changes that was about to be applied on 22nd March 2022. 2022a tzData is already released on 15th March 2022 and Iran (Asia/Tehran) DST changes are not part of this release. I want to ask what is the plan to include (Asia/Tehran) changes in tzData? Regards, Jahar Tyagi

2 2

Daylight saving in Iran changed
by Shahab Ouraie March 17, 2022

March 17, 2022

Hello. As new rule approved by government, the daylight saving time in Iran/Tehran (which was +4:30) will no longer be applied and the whole year time will be +3:30 Please consider updating this which will take effect in 4 days from now (2022 March 21st).

1 0

[tz-announce] 2022a release of tz code and data available
by Paul Eggert via tz-announce March 17, 2022

March 17, 2022

The 2022a release of the tz code and data is available. This release reflects the following changes: Briefly: Palestine will spring forward on 2022-03-27, not -03-26. zdump -v now outputs better failure indications. Bug fixes for code that reads corrupted TZif data. Changes to future timestamps Palestine will spring forward on 2022-03-27, not 2022-03-26. (Thanks to Heba Hamad.) Predict future transitions for first Sunday >= March 25. Additionally, predict fallbacks to be the first Friday on or after October 23, not October's last Friday, to be more consistent with recent practice. The first differing fallback prediction is on 2025-10-24, not 2025-10-31. Changes to past timestamps From 1992 through spring 1996, Ukraine's DST transitions were at 02:00 standard time, not at 01:00 UTC. (Thanks to Alois Treindl.) Chile's Santiago Mean Time and its LMT precursor have been adjusted eastward by 1 second to align with past and present law. Changes to commentary Add several references for Chile's 1946/1947 transitions, some of which only affected portions of the country. Changes to code Fix bug when mktime gets confused by truncated TZif files with unspecified local time. (Problem reported by Almaz Mingaleev.) Fix bug when 32-bit time_t code reads malformed 64-bit TZif data. (Problem reported by Christos Zoulas.) When reading a version 2 or later TZif file, the TZif reader now validates the version 1 header and data block only enough to skip over them, as recommended by RFC 8536 section 4. Also, the TZif reader no longer mistakenly attempts to parse a version 1 TZIf file header as a TZ string. zdump -v now outputs "(localtime failed)" and "(gmtime failed)" when local time and UT cannot be determined for a timestamp. Changes to build procedure Distribution tarballs now use standard POSIX.1-1988 ustar format instead of GNU format. Although the formats are almost identical for these tarballs, ustar headers' magic fields contain "ustar" instead of "ustar ", and their version fields contain "00" instead of " ". The two formats are planned to diverge more significantly for tzdb releases after 2242-03-16 12:56:31 UTC, when the ustar format becomes obsolete and the tarballs switch to pax format, an extension of ustar. For details about these formats, please see "pax - portable archive interchange", IEEE Std 1003.1-2017, <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022a.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 95ecc37d29c2f5cf711af43b0ef3a35fc2847aa1 dated 2022-03-15 23:02:01 -0700 and tagged '2022a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 3f047a6f414ae3df4a3d6bb9b39a1790833d191ae48e6320ab9438cd326dc455475186a02c44e4cde96b48101ab000880919b1e0e8092aed7254443ed2c831ed tzcode2022a.tar.gz 542e4559beac8fd8c4af7d08d816fd12cfe7ffcb6f20bba4ff1c20eba717749ef96e5cf599b2fe03b5b8469c0467f8cb1c893008160da281055a123dd9e810d9 tzdata2022a.tar.gz ece0b7a9ad3d365f8605e8f98a8a78b7fdbbb8aa615b585f21256d9401c59845fcdc951f5fc876293f1b7956b1a2d3fa2baf85099d637a91d4199ee30cf4307e tzdb-2022a.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmIxfhAACgkQ7ZfpDmKq fjRXfw/8DC6daRCaFirmN6821H+CA0D/e0Iod9e2g/Z5/yyx5HGCEAfRBhJ6ThWA O1I8oCuwp2kaP2ZH87+HKXT1WXGMx/819FU5fqY2TNncHAUxVUSmAm1yVHWaY2nU qFt3gDTx4vDV0lfSDtKYJJdVeE+VcAdSDUDnYIqMNCKuTkKdTfPVparsAPIZ8egr EC4IBiGolLoLkMiiwvvPNg0J505I+DUYeHEuo+ezhgBzBiLNhCWDfCcghoDYakHr CEH+aq6BVhhn/3w1203ExN7iEr/5iTwC/PjRZoJlBqDS7eAhycgFYHjglHGYSs8P RVNnkTAhDMxONZH97QqKlOo56a5QLMvTDNbBLdX0b4K4lmEfCRe03MbH4ybDkA9S +eYfkeX2kUYKnHTT3XXTiVvjDFGemu+l8QGlJoF9Qu44cUGLPZQZEq/YzbZUw8ax RaT4V0ZkH3+yMYAAWaoa85xXs7a/MnE7Gl9glSFzlijC6iZoRmrXy2ra44TzvwWr E/7Het1lctaiKWcdYH5+vYyzzWZTt4hKAXsCUgBGQy0/mE2KoHRQHk6zfZPY1TvD ib6Dkh9LWYrXsNGCe1H4SpjKEX51Nb27FgIw1DNrbOJpTna5/OKmceu5IIlGJseF nfwPHZ3ATpVfVwdiRqbNC9GNVBev9n5UI67zGQ2494kknR2JMhs= =4JUm -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmIxfhAACgkQ7ZfpDmKq fjTlWw/7BrBTwRx7HvTlNaIbCaj/uOIEomJafNOq8Kdbx2JXrZu8qhj/0vMdwIzQ CEIqVuGKD8WJB4nsBYlFU8Jn1JfRbglnWK1f7yRY1EaXuIFh+FMbRYEk8O3HYPy2 14QCJNjsCwIzztmiuxXqET2eQRpT2iojGKhZbToJE4DpC/w5xCPrUqAIsK8nfC3u TZC8l09zL/xTSl/QMStH/Kh8oJD4uftVMxYZE5zakZaH5M017gwjDdM/7I/D4MME sTm7XEL7IdzzZyTxzeVVbXfyqoEb1ueJJImYnQfGgCnoJKtMjVROzL6BBJSZLkZN tR7/V9mHZKoItzhOv5gwfk0YMy8792rAioqfMUG/KvrvCTNy3PqrE1jO1/nv+FPS WWuixsnRx1Xz2COb88pKnYX17Zt8rBIumcfpgolsBvLKGI7ZLEAekjteKubgpebn jnf6CLAdcRoIdauG483LG/OQ6M9PEUBYTrX56Q8/C3kdOPuuMJ/6qd6k7lNt/fWx O2lBg+lkIagZu8j5pU5mHOsVe2P1f7p7oIt1NF2oAD2cIq6EFWOdcOCyvgC69xE1 +jt6lIQkIfBM8dfxf70z9KZQvOr9bwZaCirWNTgIMxrn/n4vvo5HCbYx+P4LSAhH G1UY/x67Swnl0p6+69d8Ww/SrdOP3T30KxjIaQXx5NgjeU2zIEo= =OX/x -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmIxfhEACgkQ7ZfpDmKq fjTWBQ//T8ICtN33H3kcz/4P9gWArfgV7huztvWW9KKBkQpWEa9gIlpYi7jx80wF qnAHZCpRedj+CJXqswkG+lIMVLEHjwVT2hdeP5wPV2y5rJ0J9Ssh2i0voSdX000T WED4u/OyR1shKm4VIxdgY6eqaN6Hedc0+Eib/VoIQAzCM2nP3c4IMAWkBKLiCSIZ n6JVI90jRgAnzhRJjiddJRFMBovzKNIxpqGGZYaxaG0O5AYfsItdRte3RCOn/tc+ tsMSJ+iUt8nTonq4P1nUE4zmvx33V7iOJhaj03fdJal0U8Egc/Ib5exsS2KipEjG iknyi8dUQcbNBFnFoN26SAO9/QMpDDE/vOnGGyWySLSwQg/xmy+LwmIZGqVftDeX JrUeRboH/39aDx6kKIrqXeIlG9bNka/6ThOJEZNr+OejDRyFeqgcatpomRkoExRs pPR88cyA0ZsN3PHhi9eXO+Zyk9GBA0o7m7G0ECK2j6w2axPh8/xPQ94zdFRTcd3V 3xC94N42eoNKeWgEmyvNEXdq5hZXhPK/Lu8D0NScbS440ovMJJtcr8Q+/bihHyGG eOCrxVF5KXLOYvptQ/xhUGodzRm8PuZ6DkJoCtW9PQL82LZDSHAi880YgzsdWzzy 6m6g8KmOmTkmQ6vztMyDr04KW2QDxp53q7hdErh0bW0iyvELd7I= =egWc -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. This is intended to be a temporary transition aid for these parsers. To generate a rearguard-format tarball, obtain the full distribution as described above, and run the command 'make rearguard_tarballs' on a development host. Or you can run 'make rearguard.zi' to generate a single file that can be fed directly to a parser that works like 'zic'.

1 0

Permanent DST in the United States
by Jacob Pratt March 16, 2022

March 16, 2022

The "Sunshine Protection Act" has passed the US Senate with unanimous consent. It now moves on to the House. My reading of the text is that this would mandate permanent DST for the 48 states that currently observe it, with Arizona (sans the Navajo Nation) and Hawaii able to choose. Notably there is no clause that delays implementation, so it looks like it would take effect immediately. This could be problematic if the bill becomes law near or after the November clock change. https://www.congress.gov/bill/117th-congress/senate-bill/623/text Jacob Pratt

4 5

gmtime failed messages for zdump on Windows with latest git code
by Manuela Friedrich March 16, 2022

March 16, 2022

Hello Paul, I noticed that zdump on Windows from the latest git code now produces "localtime failed" and "gmtime failed" messages. Is that expected? Does it also happen on Linux? New behaviour with git code: zdump.exe -v d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan d:\zoneinfo\iana\Africa\Abidjan -9223372036854775808 (gmtime failed) = -9223372036854775808 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan -67768040609740801 (gmtime failed) = -67768040609740801 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:00:00 -2147481748 UT = -67768040609740800 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:07 -2147481748 UT = -67768040609739833 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:07 1912 UT = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:08 1912 UT = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan 67768036191676800 (gmtime failed) = 67768036191676800 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan 9223372036854775807 (gmtime failed) = 9223372036854775807 (localtime failed) Output from 2021e zdump.exe -v d:\zoneinfo\iana\Africa\Abidjan d:\zoneinfo\iana\Africa\Abidjan -9223372036854775808 = NULL d:\zoneinfo\iana\Africa\Abidjan -67768040609740801 = NULL d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:00:00 -2147481748 UT = NULL d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:07 -2147481748 UT = NULL d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:07 1912 UT = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:08 1912 UT = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan 67768036191676800 = NULL d:\zoneinfo\iana\Africa\Abidjan 9223372036854775807 = NULL Thank you! Regards Manuela Friedrich

2 2

Wouldn't it be simpler if…
by Torsten Louland March 15, 2022

March 15, 2022

https://xkcd.com/1061/

2 1

Daylight Saving: Iran
by MohamadReza Farhadi March 15, 2022

March 15, 2022

Greetings, Today Iranian Parliament approved the cancelation of the Daylight Saving Time practice. The link for the article can be found here: https://www.bbc.com/persian/iran-60734716 Kindest Regards, MohamadReza Farhadi

1 0

Hong Kong listed as UK not China
by Shelley Finerty March 15, 2022

March 15, 2022

Hi there, I was using a tool that allows me to look at people’s birthdate, time and location and noticed that you still have Hong Kong listed as part of the UK with throws off the timezone for their birthdate. I had to choose another city close to Hong Kong to use it correctly. Is this something that can be changed or updated? Or are you keeping it for historical purposes? Is there a way to do both? Thanks for keeping the time so accurately - I appreciate the work you’re doing. Shelley Finerty Canada

3 2

2022a timeline?
by Deborah Goldsmith March 15, 2022

March 15, 2022

Hi, Is there an ETA for the release of (I assume) 2022a with the change for Palestine? Thank you, Deborah Goldsmith

2 1

[PATCH] URL housekeeping
by Paul Eggert March 12, 2022

March 12, 2022

* tz-link.html: Omit no-longer-active projects, and update URLs. Mention "pytz: The Fastest Footgun in the West". --- tz-link.html | 33 ++++++++++++--------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/tz-link.html b/tz-link.html index 48724ad..92da48f 100644 --- a/tz-link.html +++ b/tz-link.html @@ -89,7 +89,6 @@ title="Berkeley Software Distribution">BSD</abbr></a>, title="Web Operating System">webOS</abbr></a>, <a href="https://en.wikipedia.org/wiki/IBM_AIX"><abbr title="Advanced Interactive eXecutive">AIX</abbr></a>, -<a href="https://en.wikipedia.org/wiki/BlackBerry_10">BlackBerry 10</a>, <a href="https://www.apple.com/ios"><abbr title="iPhone OS">iOS</abbr></a>, <a href="https://www.apple.com/macos">macOS</a>, @@ -243,18 +242,18 @@ the process by tailoring the generic instructions in the <code><abbr>tz</abbr> README</code> file and installing the latest data yourself. System-specific instructions for installing the latest <code><abbr>tz</abbr></code> data have also been published -for <a href="https://www.ibm.com/developerworks/aix/library/au-aix-olson-time-zone/index…"><abbr>AIX</abbr></a>, +for <a href="https://developer.ibm.com/articles/au-aix-olson-time-zone/"><abbr>AIX</abbr></a>, <a href="https://source.android.com/devices/tech/config/timezone-rules">Android</a>, <a -href="http://userguide.icu-project.org/datetime/timezone"><abbr +href="https://unicode-org.github.io/icu/userguide/datetime/timezone/"><abbr title="International Components for Unicode">ICU</abbr></a>, -<a href="https://developer.ibm.com/javasdk/support/dst/jtzu/"><abbr>IBM</abbr> +<a href="https://www.ibm.com/support/pages/java-sdk-time-zone-update-utility"><abbr>IBM</abbr> JDK</a>, <a href="https://www.joda.org/joda-time/tz_update.html">Joda-Time</a>, <a href="https://dev.mysql.com/doc/refman/en/time-zone-support.html">MySQL</a>, <a href="https://nodatime.org/userguide/tzdb">Noda Time</a>, and <a -href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html#usage">OpenJDK/Oracle JDK</a>. +href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">OpenJDK/Oracle JDK</a>. </p> <p>Sources for the <code><abbr>tz</abbr></code> database are <a href="https://en.wikipedia.org/wiki/UTF-8"><abbr @@ -488,11 +487,6 @@ many of which also support runtimes lacking the <samp>timeZone</samp> option. href="https://github.com/formatjs/date-time-format-timezone"><samp>Intl.DateTimeFormat</samp> timezone polyfill</a> is freely available under a <abbr>BSD</abbr>-style license.</li> -<li><a -href="https://github.com/kshetline/compact-time-zone-generator">CompactTimeZoneGenerator</a> -compiles time zone data into a compact form designed for -JavaScript. It is freely available under a combination of -the <abbr>MIT</abbr> license and the Apache License.</li> <li>The <a href="https://date-fns.org/">date-fns</a> library manipulates timezone-aware timestamps in browsers and in <a href="https://nodejs.org/en/">Node.js</a>. @@ -546,9 +540,9 @@ It is freely available under a <abbr>BSD</abbr>-style license.</li> Definitions for Python</a> compiles <code><abbr>tz</abbr></code> source into <a href="https://www.python.org">Python</a>. It is freely available under a <abbr>BSD</abbr>-style license. -In code that can assume Python 3.9 or later it is superseded by -<a href="#python-zoneinfo"><code>zoneinfo.ZoneInfo</code></a> -and the <a href="#pypi-tzdata"><code>tzdata</code> Python package</a>.</li> +In code that can assume Python 3.6 or later it is largely superseded; see <a +href="https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html">pytz: +The Fastest Footgun in the West</a>.</li> <li><a href="https://tzinfo.github.io">TZInfo – Ruby Timezone Library</a> compiles <code><abbr>tz</abbr></code> source into @@ -610,11 +604,11 @@ is a <abbr>TZif</abbr> file reader written in Perl. It is freely available under the same terms as Perl (dual <abbr>GPL</abbr> and Artistic license).</li> <li>Python has a <a id="python-zoneinfo" -href="https://docs.python.org/3.9/library/zoneinfo.html"><code>zoneinfo.ZoneInfo</code> +href="https://docs.python.org/3/library/zoneinfo.html"><code>zoneinfo.ZoneInfo</code> class</a> that reads <abbr>TZif</abbr> data and creates objects that represent <code><abbr>tzdb</abbr></code> timezones. Python is freely available under the -<a href="https://docs.python.org/3.9/license.html">Python Software Foundation +<a href="https://docs.python.org/3/license.html">Python Software Foundation License</a>. A companion <a id="pypi-tzdata" href="https://pypi.org/">PyPI</a> module <a href="https://pypi.org/project/tzdata/"><code>tzdata</code></a> @@ -641,7 +635,7 @@ available under a <abbr>BSD</abbr>-style license.</li> <li><a href="https://foxclocks.org">FoxClocks</a> is an extension for <a href="https://www.google.com/chrome/">Google Chrome</a> and for <a -href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Toolkit_API">Mozilla +href="https://wiki.mozilla.org/Modules/Toolkit">Mozilla Toolkit</a> applications like <a href="https://www.mozilla.org/en-US/firefox/new/">Firefox</a> and <a href="https://www.mozilla.org/en-US/thunderbird/">Thunderbird</a>. @@ -1010,14 +1004,11 @@ specifies a <a href="https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol"><abbr>DHCP</abbr></a> option for a server to configure a client's time zone and daylight saving settings automatically.</li> -<li><a -href="https://www.cv.nrao.edu/~rfisher/Ephemerides/times.html">Astronomical -Times</a> explains more abstruse astronomical time scales like +<li><a href="https://www.ucolick.org/~sla/leapsecs/timescales.html">Time +Scales</a> describes astronomical time scales like <abbr title="Terrestrial Dynamic Time">TDT</abbr>, <abbr title="Geocentric Coordinate Time">TCG</abbr>, and <abbr title="Barycentric Dynamic Time">TDB</abbr>. -<a href="https://www.ucolick.org/~sla/leapsecs/timescales.html">Time -Scales</a> goes into more detail, particularly for historical variants.</li> <li>The <a href="https://www.iau.org"><abbr title="International Astronomical Union">IAU</abbr></a>'s <a href="http://www.iausofa.org"><abbr -- 2.32.0

1 0

Just :)
by Sergiusz Wolicki March 11, 2022

March 11, 2022

Ryan Reynolds (@VancityReynolds) wysłał/a Tweeta o godz. 3:29 PM on pt., mar 11, 2022: As if making #TheAdamProject hadn’t satisfied enough of my childhood dreams, this happened. (I still loathe Daylight Savings.) https://t.co/9lAjYzjOnW ( https://twitter.com/VancityReynolds/status/1502290590242910208?t=zCwO45RshV… )

1 0

Re: [tz] Summer time
by heba.hamad＠mtit.gov.ps March 10, 2022

March 10, 2022

Dear sir, regarding to summer time for this year , the timing will be on 3/27/2022, but this does not necessarily mean that the change for the coming years will be on the same date. You will be provided with any new decisions about summer and winter times for the coming years and we will try to provide you with any changes more earlier than previous years. BR, في الخميس, مارس 10, 2022 14:26 EST, Paul Eggert <eggert(a)cs.ucla.edu> كتب: 3/04:50,http://www.palestinecabinet.gps/portal/Meeting/Details/51955 heba.hamad(a)mtit.gov.ps wrote: > We would like to inform you that the summer time will begin in Palestine from Sunday 03-27-2022 ,00:00 AM by 60 minutes forward. Thanks, do you have a URL for that announcement? It sounds like Palestine is changing its spring-forward rules, so that Palestine will now spring forward at 00:00 on the first Sunday on or after March 25, whereas during 2020 and 2021 Palestine sprang forward at 00:00 on the first Saturday after March 24. Is my understanding correct? Knowing the transition rule would be helpful, because TZDB makes predictions about future years, some computer applications rely on this (perhaps unwisely, but that's what they do), and the more accurate the predictions the better off everybody will be. This is related to Clive Feather's point that we need plenty of advance notice of rule changes (we'd like a year's notice). Without knowing the answers to the above questions, I installed the attached proposed patch into the TZDB development version. If possible, I'd like to improve this (based on answers to the above questions) before the next TZDB release, which should happen soon.

1 0

Summer time
by heba.hamad＠mtit.gov.ps March 10, 2022

March 10, 2022

Dear Sir, Greeting from Ministry of telecom and information technology, Palestine We would like to inform you that the summer time will begin in Palestine from Sunday 03-27-2022 ,00:00 AM by 60 minutes forward. Kindly find the attachment below that includes the decision of the Palestinian cabinet. BR

3 2