From eggert at cs.ucla.edu Fri May 1 18:51:49 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 1 May 2020 11:51:49 -0700 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: On 5/1/20 8:49 AM, Sergio Bonfiglio wrote: > https://timezonedb.com/ tz-link.html mentions TimeZoneDB under "Time zone boundaries" but it'd be good to also mention their CSV and SQL downloads. I installed the attached proposed patch to try to do that. > in Italy there are 3 zones, not only ROME but also Palermo (Sicily island > complete) and Cagliari (Sardinia island complete), which differ from each > other, also if slightly in time. > How can I add these two zones to the data ? Because these zones are identical to Europe/Rome for timestamps after 1970, they're out of scope for tzdb proper . However, we do have a file 'backzone' for out-of-scope data (this file is not normally used in tzdb installations). So you can send in a patch for that file if you like, preferably in 'git format-patch' form. See Europe/Belfast for an example of what might appear in 'backzone'. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Mention-TimeZoneDB-s-CSV-and-SQL-files.patch Type: text/x-patch Size: 1948 bytes Desc: not available URL: From eggert at cs.ucla.edu Fri May 1 20:26:19 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 1 May 2020 13:26:19 -0700 Subject: [tz] [PROPOSED] More Ruthenia replacement Message-ID: <20200501202619.31323-1-eggert@cs.ucla.edu> This follows up on an earlier patch in March, which replaced ?Ruthenia? with ?Transcarpathia? but missed a couple of instances. * europe: Ruthenia?Transcarpathia in commentary here, too. * theory.html: Switch to Europe/Prague as a more easily-understood example. --- europe | 2 +- theory.html | 10 ++++------ 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/europe b/europe index 5593c60..91949d6 100644 --- a/europe +++ b/europe @@ -3983,7 +3983,7 @@ Zone Europe/Kiev 2:02:04 - LMT 1880 2:00 1:00 EEST 1991 Sep 29 3:00 2:00 E-Eur EE%sT 1995 2:00 EU EE%sT -# Ruthenia used CET 1990/1991. +# Transcarpathia used CET 1990/1991. # "Uzhhorod" is the transliteration of the Rusyn/Ukrainian pronunciation, but # "Uzhgorod" is more common in English. Zone Europe/Uzhgorod 1:29:12 - LMT 1890 Oct diff --git a/theory.html b/theory.html index c0e6f02..ffa3b4d 100644 --- a/theory.html +++ b/theory.html @@ -115,17 +115,15 @@ Each timezone has a name that uniquely identifies the timezone. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like -"Ruthenia" instead of the timezone name "Europe/Uzhgorod". +"Czech Republic" instead of the timezone name "Europe/Prague". If geolocation information is available, a selection interface can locate the user on a timezone map or prioritize names that are geographically close. For an example selection interface, see the tzselect program in the tz code. -The Unicode Common Locale Data +The Unicode Common Locale Data Repository contains data that may be useful for other selection -interfaces; it maps timezone names like Europe/Uzhgorod -to CLDR names like uauzh which are in turn mapped to -locale-dependent strings like "Uzhhorod", "Ungv?r", "???????", and -"?????". +interfaces; it maps timezone names like Europe/Prague to +locale-dependent strings like "Prague", "Praha", "?????", and "???".

-- 2.17.1 From reecestewart550 at gmail.com Fri May 1 20:58:01 2020 From: reecestewart550 at gmail.com (Reece Stewart) Date: Sat, 2 May 2020 06:58:01 +1000 Subject: [tz] tz Digest, Vol 104, Issue 1 In-Reply-To: References: Message-ID: Stop sending me should your fucken dogs On Fri., 1 May 2020, 10:00 pm , wrote: > Send tz mailing list submissions to > tz at iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request at iana.org > > You can reach the person managing the list at > tz-owner at iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. Database available in other formats (Sergio Bonfiglio) > 2. Re: Database available in other formats (Paul Eggert) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Apr 2020 17:12:55 +0200 > From: Sergio Bonfiglio > To: tz at iana.org > Subject: [tz] Database available in other formats > Message-ID: > < > CANCwfxiVBnHPUawqZxWEKU+W89PWxL0SNRUXAMLgX1iMTMUF7Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Sirs, > > First thig first a big THANK YOU for your invaluable work. > I was overwhelmed by the complexity of your database, because it requires > also external pieces of code to be safely read. > I was wondering if does exist the database in different formats that may be > larger but more readable and easy usable. > An SQL database could be really "for everyone", because can be queried by > everything from everywhere by any language. > If I may make a humble suggestion, a JD date in floating format that equips > any record with the initial and final date of the rule/event could be of > great help. > With a single query, one could recall all the records that pertain a > certain moment in time also with different and overlapping rules. > Thanks for any reply and thank for your work that is making me sweat the > classical " seven shirts". > Stay well > > Sergio Bonfiglio > ITALY > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mm.icann.org/pipermail/tz/attachments/20200428/1489fee1/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 30 Apr 2020 13:39:06 -0700 > From: Paul Eggert > To: Sergio Bonfiglio > Cc: Time zone mailing list > Subject: Re: [tz] Database available in other formats > Message-ID: > Content-Type: text/plain; charset=utf-8 > > On 4/28/20 8:12 AM, Sergio Bonfiglio wrote: > > > I was overwhelmed by the complexity of your database, because it requires > > also external pieces of code to be safely read. > > Yes, it's in its own .zi format. Typically I edit it with a text editor so > I > suppose that counts as an external piece of code. Most people either do > that, or > process it with the code supplied as part of tzdb, or use one of the > already-written tz compilers > . Perhaps one of > those > will work for you. > > > An SQL database could be really "for everyone", because can be queried by > > everything from everywhere by any language. > > MariaDB, MySQL, and Oracle Database use tzdb in some form; perhaps they're > already doing something along the lines of what you're asking for. > > > If I may make a humble suggestion, a JD date in floating format that > equips > > any record with the initial and final date of the rule/event could be of > > great help. > > JD should be relatively easy to generate automatically from the existing > format. > I doubt whether the source data should have JD directly, though, as JD is > inconvenient for humans and anyway the .zi format is now read by so many > programs that any changes to it would need to be carefully considered and > justified. But JD could be good for database queries, along the lines of > your > suggestion. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tz mailing list > tz at iana.org > https://mm.icann.org/mailman/listinfo/tz > > _______________________________________________ > By submitting your personal data, you consent to the processing of your > personal data for purposes of subscribing to this mailing list accordance > with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and > the website Terms of Service (https://www.icann.org/privacy/tos). You can > visit the Mailman link above to change your membership status or > configuration, including unsubscribing, setting digest-style delivery or > disabling delivery altogether (e.g., for a vacation), and so on. > > ------------------------------ > > End of tz Digest, Vol 104, Issue 1 > ********************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonfiglio.sergio at gmail.com Fri May 1 15:49:07 2020 From: bonfiglio.sergio at gmail.com (Sergio Bonfiglio) Date: Fri, 1 May 2020 17:49:07 +0200 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: Dear Paul, thanks for the reply. I have found that there could be some versions already available of the TZ database that could suit my needs. In order to make a due reply to your suggestions I'd tell something about your responses and I'd like too to submit you some topics that I need to confront with. The first topic is this: the UNIX date that is supported in many compilers has some limitation in order to the dates preceding Jan 1 1970. The second topic is that some of the compilers you (greatly) list onto your page are not updated at the last version of data, like for instance the Delphi version - right the one I'd like to use - which is - strange to say - includes the data WITHIN the code, that is something really against the most simple rules of Information Technology that is to keep data separated from the code. So for what this is the solution of this problem I think I will go to some other resource, that is another that I haven't found listed into your page (unless I have resoundingly missed it) that is this one: https://timezonedb.com/ These great guys provide a MySQL version of the TZ database that seems also up-to-date (I have to check it out but it is promising) and I think you should nicely include this resource into your list (unless, I repeat, I have missed it and this is just in the list already. In this case I apologize for that). I have an idea about making a software to keep the TZ database updated. I will talk you in the future If I decide to carry on this work. The third issue is what I have with Italian zones listed in the TZ, because as you correctly state in the description notes of the "europe" file, In Italy there are 3 zones, not only ROME but also Palermo (Sicily island complete) and Cagliari (Sardinia island complete), which differ from each other, also if slightly in time. How can I add these two zones to the data ? May I kindly ask you to include these two zones in some the future releases of the database ? Thanks again for your great help and your invaluable work. Sergio Bonfiglio Il giorno gio 30 apr 2020 alle ore 22:39 Paul Eggert ha scritto: > On 4/28/20 8:12 AM, Sergio Bonfiglio wrote: > > > I was overwhelmed by the complexity of your database, because it requires > > also external pieces of code to be safely read. > > Yes, it's in its own .zi format. Typically I edit it with a text editor so > I > suppose that counts as an external piece of code. Most people either do > that, or > process it with the code supplied as part of tzdb, or use one of the > already-written tz compilers > . Perhaps one of > those > will work for you. > > > An SQL database could be really "for everyone", because can be queried by > > everything from everywhere by any language. > > MariaDB, MySQL, and Oracle Database use tzdb in some form; perhaps they're > already doing something along the lines of what you're asking for. > > > If I may make a humble suggestion, a JD date in floating format that > equips > > any record with the initial and final date of the rule/event could be of > > great help. > > JD should be relatively easy to generate automatically from the existing > format. > I doubt whether the source data should have JD directly, though, as JD is > inconvenient for humans and anyway the .zi format is now read by so many > programs that any changes to it would need to be carefully considered and > justified. But JD could be good for database queries, along the lines of > your > suggestion. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonfiglio.sergio at gmail.com Fri May 1 21:13:56 2020 From: bonfiglio.sergio at gmail.com (Sergio Bonfiglio) Date: Fri, 1 May 2020 23:13:56 +0200 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: Thanks, I'll check them out. Sergio Il giorno ven 1 mag 2020 alle ore 20:51 Paul Eggert ha scritto: > On 5/1/20 8:49 AM, Sergio Bonfiglio wrote: > > > https://timezonedb.com/ > > tz-link.html mentions TimeZoneDB under "Time zone boundaries" but it'd be > good > to also mention their CSV and SQL downloads. I installed the attached > proposed > patch to try to do that. > > > in Italy there are 3 zones, not only ROME but also Palermo (Sicily island > > complete) and Cagliari (Sardinia island complete), which differ from each > > other, also if slightly in time. > > How can I add these two zones to the data ? > > Because these zones are identical to Europe/Rome for timestamps after 1970, > they're out of scope for tzdb proper > . However, we do have > a file > 'backzone' for out-of-scope data (this file is not normally used in tzdb > installations). So you can send in a patch for that file if you like, > preferably > in 'git format-patch' form. See Europe/Belfast for an example of what might > appear in 'backzone'. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eggert at cs.ucla.edu Sun May 3 22:28:05 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 3 May 2020 15:28:05 -0700 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: <94d4ff4f-7529-76e3-6577-df430f1d46a2@cs.ucla.edu> On 5/3/20 5:48 AM, Sergio Bonfiglio wrote: > I don't know what to do with the file 0001-Mention.... etc. that you sent > me. > Must I apply to a git clone or something ? You could do that, yes. Or you could simply clone the current development version , as it has the patch already applied. Eventually the development version should evolve into the next release. From andrew at tao11.riddles.org.uk Mon May 4 02:36:20 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Mon, 04 May 2020 03:36:20 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" Message-ID: <877dxs36bj.fsf@news-spur.riddles.org.uk> In a post on this list on Nov 24 last, Garret Wollman said regarding FreeBSD's c.1994 change (now reversed) to not install "backward": >> I chose not to install the "backward" zones in the hope that this >> would more securely deprecate the then-recently-obsoleted old-style >> names like "US/Eastern", and then maybe they could be completely >> removed from the distribution if other downstream consumers (only a >> few operating systems at that point, no language runtimes) would do >> likewise. >> Unfortunately, these ancient compatibility links never got deleted, >> so "backward" now contains a mix of ancient and more recent >> compatibility links, and users are still using them (or being told >> to use them by documentation that should have been updated decades >> ago). The obvious way to resolve this would be to split "backward" into two: one file containing aliases that were once regarded as canonical names (or at least names consistent with current naming theory) but were then renamed (e.g. the recent example of Godthab -> Nuuk), the other containing all the ancient stuff that never conformed to the current style (such as "W-SU", "Poland", "GB-Eire", "US/Eastern" etc.). One way to do this might be to set a cutoff date, for which the 2000a data release seems like a good choice, and retain only the zones changed since then in "backward", moving the remainder to a new "deprecated" category. Another way would be to reserve "backward" for zones that have appeared in zone.tab at any time, and move the rest to "deprecated". It turns out that these two methods give almost exactly the same results, with only two exceptions: America/Ensenada was in "backward" before 2000 going by the SCM history, but existed in zone.tab until 2010; and Asia/Ulan_Bator was added to "backward" and removed from zone.tab in the 2000a release. This suggests that the zone.tab criterion is a slightly better one. (One further exception should be made: the link from Etc/UTC to UTC is in widespread use and should probably be moved to "etcetera" alongside the similar "GMT" link. Otherwise it should stay in "backward". This change already exists in FreeBSD, where all "GMT" defaults have been changed to "UTC" at some point.) Split this way, the list of links in "backward" would become (posted in plain text here for readability, I can submit in patch form if needed) as follows: Link Africa/Nairobi Africa/Asmera Link Africa/Abidjan Africa/Timbuktu Link America/Argentina/Catamarca America/Argentina/ComodRivadavia Link America/Argentina/Buenos_Aires America/Buenos_Aires Link America/Argentina/Catamarca America/Catamarca Link America/Atikokan America/Coral_Harbour Link America/Argentina/Cordoba America/Cordoba Link America/Tijuana America/Ensenada Link America/Nuuk America/Godthab Link America/Indiana/Indianapolis America/Indianapolis Link America/Argentina/Jujuy America/Jujuy Link America/Kentucky/Louisville America/Louisville Link America/Argentina/Mendoza America/Mendoza Link America/Toronto America/Montreal Link America/Rio_Branco America/Porto_Acre Link America/Argentina/Cordoba America/Rosario Link America/Tijuana America/Santa_Isabel Link America/Denver America/Shiprock Link Pacific/Auckland Antarctica/South_Pole Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Kolkata Asia/Calcutta Link Asia/Shanghai Asia/Chongqing Link Asia/Shanghai Asia/Chungking Link Asia/Dhaka Asia/Dacca Link Asia/Shanghai Asia/Harbin Link Asia/Urumqi Asia/Kashgar Link Asia/Kathmandu Asia/Katmandu Link Asia/Macau Asia/Macao Link Asia/Yangon Asia/Rangoon Link Asia/Ho_Chi_Minh Asia/Saigon Link Asia/Thimphu Asia/Thimbu Link Asia/Makassar Asia/Ujung_Pandang Link Asia/Ulaanbaatar Asia/Ulan_Bator Link Atlantic/Faroe Atlantic/Faeroe Link Europe/Oslo Atlantic/Jan_Mayen Link Etc/UTC Etc/UCT Link Europe/London Europe/Belfast Link Europe/Chisinau Europe/Tiraspol Link Pacific/Honolulu Pacific/Johnston Link Pacific/Pohnpei Pacific/Ponape Link Pacific/Chuuk Pacific/Truk Link Pacific/Chuuk Pacific/Yap Link Etc/UTC UTC "deprecated" would contain these links: Link America/Adak America/Atka Link America/Indiana/Indianapolis America/Fort_Wayne Link America/Indiana/Knox America/Knox_IN Link America/Port_of_Spain America/Virgin Link Asia/Jerusalem Asia/Tel_Aviv Link Australia/Sydney Australia/ACT Link Australia/Sydney Australia/Canberra Link Australia/Lord_Howe Australia/LHI Link Australia/Sydney Australia/NSW Link Australia/Darwin Australia/North Link Australia/Brisbane Australia/Queensland Link Australia/Adelaide Australia/South Link Australia/Hobart Australia/Tasmania Link Australia/Melbourne Australia/Victoria Link Australia/Perth Australia/West Link Australia/Broken_Hill Australia/Yancowinna Link America/Rio_Branco Brazil/Acre Link America/Noronha Brazil/DeNoronha Link America/Sao_Paulo Brazil/East Link America/Manaus Brazil/West Link America/Halifax Canada/Atlantic Link America/Winnipeg Canada/Central Link America/Toronto Canada/Eastern Link America/Edmonton Canada/Mountain Link America/St_Johns Canada/Newfoundland Link America/Vancouver Canada/Pacific Link America/Regina Canada/Saskatchewan Link America/Whitehorse Canada/Yukon Link America/Santiago Chile/Continental Link Pacific/Easter Chile/EasterIsland Link America/Havana Cuba Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London GB Link Europe/London GB-Eire Link Etc/GMT GMT+0 Link Etc/GMT GMT-0 Link Etc/GMT GMT0 Link Etc/GMT Greenwich Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran Link Asia/Jerusalem Israel Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein Link Africa/Tripoli Libya Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC Link Pacific/Pago_Pago Pacific/Samoa Link Europe/Warsaw Poland Link Europe/Lisbon Portugal Link Asia/Taipei ROC Link Asia/Seoul ROK Link Asia/Singapore Singapore Link Europe/Istanbul Turkey Link Etc/UTC UCT Link America/Anchorage US/Alaska Link America/Adak US/Aleutian Link America/Phoenix US/Arizona Link America/Chicago US/Central Link America/Indiana/Indianapolis US/East-Indiana Link America/New_York US/Eastern Link Pacific/Honolulu US/Hawaii Link America/Indiana/Knox US/Indiana-Starke Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific Link Pacific/Pago_Pago US/Samoa Link Etc/UTC Universal Link Europe/Moscow W-SU Link Etc/UTC Zulu -- Andrew. From bonfiglio.sergio at gmail.com Sun May 3 12:48:51 2020 From: bonfiglio.sergio at gmail.com (Sergio Bonfiglio) Date: Sun, 3 May 2020 14:48:51 +0200 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: Dear Paul, I don't know what to do with the file 0001-Mention.... etc. that you sent me. Must I apply to a git clone or something ? Would you apply to the official page, so you sent it to me for a sort of approval ? Excuse my ignorance, please. Sergio Il giorno ven 1 mag 2020 alle ore 20:51 Paul Eggert ha scritto: > On 5/1/20 8:49 AM, Sergio Bonfiglio wrote: > > > https://timezonedb.com/ > > tz-link.html mentions TimeZoneDB under "Time zone boundaries" but it'd be > good > to also mention their CSV and SQL downloads. I installed the attached > proposed > patch to try to do that. > > > in Italy there are 3 zones, not only ROME but also Palermo (Sicily island > > complete) and Cagliari (Sardinia island complete), which differ from each > > other, also if slightly in time. > > How can I add these two zones to the data ? > > Because these zones are identical to Europe/Rome for timestamps after 1970, > they're out of scope for tzdb proper > . However, we do have > a file > 'backzone' for out-of-scope data (this file is not normally used in tzdb > installations). So you can send in a patch for that file if you like, > preferably > in 'git format-patch' form. See Europe/Belfast for an example of what might > appear in 'backzone'. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elseifthen at gmx.com Mon May 4 16:02:16 2020 From: elseifthen at gmx.com (J William Piggott) Date: Mon, 4 May 2020 12:02:16 -0400 (EDT) Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <877dxs36bj.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> Message-ID: On Mon, 4 May 2020, Andrew Gierth wrote: ... >8 > Another way would be to reserve "backward" for zones that have appeared > in zone.tab at any time, and move the rest to "deprecated". > ... >8 > > (One further exception should be made: the link from Etc/UTC to UTC is I tried to get UTC added to zone.tab back on 9 Mar 2016; but received a lot of push back. Everyone seemed to be hung up on the use-case definition that UTC is an enigma, existing everywhere and nowhere at the same time. Heads exploded at the thought of UTC having a geographic connection, which it does. Enumerating that connection in no way inhibits the enigma use-case, IMO. It is incomprehensible to me that a database built around a single reference, makes that reference unreachable from within, for lack of better a term, its API. There are many projects, both hardware and software, that use zone.tab as the Time Zone Database API. For these projects, if it's not in zone.tab it does not exist. For example, in my GPS hardware I'm forced to use Reykjavik for UTC. The geographic tie is just a API lookup index, any zone can be used at any location. If I'm in Tokyo, I can still use the New York zone, even though that zone has a North American geographic tie. UTC having a geographic tie doesn't in anyway inhibit its global use. Another complaint was that a single locale is not a zone. The DB already contains single point 'zones' in Antarctica, which are in zone.tab. ... >8 > -- > Andrew. > From Brian.Inglis at SystematicSw.ab.ca Mon May 4 23:41:23 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Mon, 4 May 2020 17:41:23 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <877dxs36bj.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> Message-ID: On 2020-05-03 20:36, Andrew Gierth wrote: > (One further exception should be made: the link from Etc/UTC to UTC is > in widespread use and should probably be moved to "etcetera" alongside > the similar "GMT" link. Otherwise it should stay in "backward". This > change already exists in FreeBSD, where all "GMT" defaults have been > changed to "UTC" at some point.) It is not clear what you mean by saying FreeBSD changed GMT defaults to UTC at some point. There is a subtle distinction here as legal time in English common law derived legal systems is established by precedent, as GMT based mean solar time, not on the ITU time scale based on the SI second with leap seconds UTC. The difference between the legal basis of time derived from solar observations and calculations, and the practice of disseminating time derived from UTC, has not yet been tested in law, so dropping any distinction could be problematic, especially now, with GB divorcing EU, to give English common law renewed hegemony over GB laws in devolved assemblies, except for NI as regards time. The statute in primary effect in England, Wales, and Scotland is still: http://statutes.org.uk/site/the-statutes/nineteenth-century/1880-43-44-victoria-c-9-definition-of-time-act/ and it also currently pertains to NI, Isle of Man, the Channel Islands of Jersey, Guernsey, Alderney, Sark; and by reference to GMT (often in local equivalents of Interpretation, or Definition of Time, Acts), also to Ireland, Belgium, Portugal, Canaries, Iceland, Faeroes, Canada, and a number of African former territories of the British Empire and current members of the Commonwealth (of Nations). -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. From andrew at tao11.riddles.org.uk Tue May 5 00:26:22 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Tue, 05 May 2020 01:26:22 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: (Brian Inglis's message of "Mon, 4 May 2020 17:41:23 -0600") References: <877dxs36bj.fsf@news-spur.riddles.org.uk> Message-ID: <87zhan9ryy.fsf@news-spur.riddles.org.uk> >>>>> "Brian" == Brian Inglis writes: >> (One further exception should be made: the link from Etc/UTC to UTC >> is in widespread use and should probably be moved to "etcetera" >> alongside the similar "GMT" link. Otherwise it should stay in >> "backward". This change already exists in FreeBSD, where all "GMT" >> defaults have been changed to "UTC" at some point.) Brian> It is not clear what you mean by saying FreeBSD changed GMT Brian> defaults to UTC at some point. I mean that where the tzcode uses "GMT" as a default zone name or abbreviation in the absence of data, FreeBSD uses "UTC" (and has since 2004). e.g. with no /etc/localtime file, % env -u TZ date Tue 5 May 2020 00:00:37 UTC (To the best of my knowledge there are no reference clocks available to which one could synchronize in order to use a mean solar time, so your argument seems to me to support this choice.) -- Andrew. From eggert at cs.ucla.edu Tue May 5 00:46:52 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 4 May 2020 17:46:52 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87zhan9ryy.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> On 5/4/20 5:26 PM, Andrew Gierth wrote: > I mean that where the tzcode uses "GMT" as a default zone name or > abbreviation in the absence of data, FreeBSD uses "UTC" (and has since > 2004). It would be easy enough to replace the "GMT" in localtime.c and the "TZ=GMT0" in date.c with their UTC counterparts. This issue is somewhat independent of what's in 'backward', though, because this stuff is hard-coded in tzcode and tzdata's contents don't affect it. Getting back to the main point, I'm not sure it's worth deprecating links like 'US/Pacific' any time soon, as so many people use them and their cost is not great. It might be worth coming up with some division of the existing 'backward' file (e.g., recently-backward names vs older-backward names), although I'm not sure what that would look like. I suppose we could have a comment associated with each name saying when it became backward, though that'd increase maintenance hassle. From philip at trouble.is Tue May 5 01:57:19 2020 From: philip at trouble.is (Philip Paeps) Date: Tue, 05 May 2020 09:57:19 +0800 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> Message-ID: <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> On 2020-05-05 08:46:52 (+0800), Paul Eggert wrote: > Getting back to the main point, I'm not sure it's worth deprecating > links like 'US/Pacific' any time soon, as so many people use them and > their cost is not great. As far as FreeBSD is concerned: since we haven't installed 'US/Pacific' since ca 1994, I'm pretty sure nobody uses it. :-) Since you mention cost though: installing the backward zones increased the footprint of /usr/share/zoneinfo from about 1.8M to about 3.3M. I don't consider that worth losing sleep over in 2020. People who build systems where every megabyte counts probably don't ship /usr/share/zoneinfo in the first place. Or they can trivially patch the build system not to install backward zones. > It might be worth coming up with some division of the existing > 'backward' file (e.g., recently-backward names vs older-backward > names), although I'm not sure what that would look like. I suppose we > could have a comment associated with each name saying when it became > backward, though that'd increase maintenance hassle. Adding a comment stating when the name became backward isn't a huge additional maintenance burden. Especially since we don't move things to backward all that often. The division into backward and deprecated could be scripted based on that comment. Adding the historical comments would be a bit of work though. We could also split backward as Andrew proposes and start tagging additions to backward going forward. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From PaulGBoulder at AIM.com Tue May 5 01:58:42 2020 From: PaulGBoulder at AIM.com (Paul Gilmartin) Date: Mon, 4 May 2020 19:58:42 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87zhan9ryy.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: On 2020-05-04, at 18:26:22, Andrew Gierth wrote: > > I mean that where the tzcode uses "GMT" as a default zone name or > abbreviation in the absence of data, FreeBSD uses "UTC" (and has since > 2004). > > e.g. with no /etc/localtime file, > > % env -u TZ date > Tue 5 May 2020 00:00:37 UTC > > (To the best of my knowledge there are no reference clocks available to > which one could synchronize in order to use a mean solar time, so your > argument seems to me to support this choice.) > Do you mean mean solar time at some arbitrary precise longitude or mean solar time at the Prime Meridian? If the latter, is interpolated UT1 a close enough approximation?: https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination -- gil From andrew at tao11.riddles.org.uk Tue May 5 03:00:18 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Tue, 05 May 2020 04:00:18 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> (Philip Paeps's message of "Tue, 05 May 2020 09:57:19 +0800") References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> Message-ID: <87tv0v9jkm.fsf@news-spur.riddles.org.uk> >>>>> "Philip" == Philip Paeps writes: Philip> Since you mention cost though: installing the backward zones Philip> increased the footprint of /usr/share/zoneinfo from about 1.8M Philip> to about 3.3M. Really? Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most. Philip> Or they can trivially patch the build system not to install Philip> backward zones. Well, there used to be a build option for that in the base system, but somebody just took it out... -- Andrew. From andrew at tao11.riddles.org.uk Tue May 5 03:06:04 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Tue, 05 May 2020 04:06:04 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> (Paul Eggert's message of "Mon, 4 May 2020 17:46:52 -0700") References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> Message-ID: <87pnbj9j95.fsf@news-spur.riddles.org.uk> >>>>> "Paul" == Paul Eggert writes: Paul> Getting back to the main point, I'm not sure it's worth Paul> deprecating links like 'US/Pacific' any time soon, as so many Paul> people use them Are there any statistics on that? The US/* names are one thing, but what about the nonsense like "W-SU"? The random selection of places that get top-level entries for no readily apparent reason? If there's actual usage justification for keeping US/* specifically in backward, or making it its own compatibility file, I have no particular objection, but it doesn't justify not clearing up the rest of the mess. -- Andrew. From philip at trouble.is Tue May 5 03:16:42 2020 From: philip at trouble.is (Philip Paeps) Date: Tue, 05 May 2020 11:16:42 +0800 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87tv0v9jkm.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: On 2020-05-05 11:00:18 (+0800), Andrew Gierth wrote: > Philip Paeps wrote: >> Since you mention cost though: installing the backward zones >> increased the footprint of /usr/share/zoneinfo from about 1.8M to >> about 3.3M. > > Really? > > Installing "backward" should create only links, and therefore have > negligible effect on the size, the only real penalty being the extra > directories and entries which should be only a few blocks at most. It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely). >> Or they can trivially patch the build system not to install backward >> zones. > > Well, there used to be a build option for that in the base system, but > somebody just took it out... Easy enough to put back if someone yells about it. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From eggert at cs.ucla.edu Tue May 5 03:41:46 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 4 May 2020 20:41:46 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: On 5/4/20 8:16 PM, Philip Paeps wrote: > It looks like we install the files rather than links.? Or I've botched something > on the test machine I looked at (which is not unlikely). If you're installing files then that should get fixed. In tzdb on my Fedora 31 platform (ext4 filesystem with 4 KiB blocks), 'make install' creates a zoneinfo directory that 'du' reports consumes 1800 KiB, as opposed to the 1776 KiB consumed for the same directory with 'make BACKWARD="" install'. The 24 KiB difference comes mostly from the five extra directories implied by 'backward' (Brazil, Canada, Chile, Mexico, US) each of which consume 4 KiB; the rest comes from the larger tzdata.zi file (108 vs 112 KiB allocated, due to the extra -L lines). >>> Or they can trivially patch the build system not to install backward zones. >> >> Well, there used to be a build option for that in the base system, but >> somebody just took it out... > > Easy enough to put back if someone yells about it. Might make sense to put it back in (if only for compatibility with older FreeBSD systems where TZ='W-SU' gave you UTC :-). From eggert at cs.ucla.edu Tue May 5 03:48:36 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 4 May 2020 20:48:36 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87pnbj9j95.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <87pnbj9j95.fsf@news-spur.riddles.org.uk> Message-ID: On 5/4/20 8:06 PM, Andrew Gierth wrote: >>>>>> "Paul" == Paul Eggert writes: > > Paul> Getting back to the main point, I'm not sure it's worth > Paul> deprecating links like 'US/Pacific' any time soon, as so many > Paul> people use them > > Are there any statistics on that? > > The US/* names are one thing, but what about the nonsense like "W-SU"? I don't know of any statistics. A quick Google search suggests that TZ='US/Pacific' is far more common than TZ='W-SU'. That being said, I did find a few instances of the latter, including: http://forum.ixbt.com/topic.cgi?id=24:29252 https://github.com/rstudio/bookdown/issues/440 https://postgrespro.ru/list/thread-id/1220710 From andrew at tao11.riddles.org.uk Tue May 5 04:07:35 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Tue, 05 May 2020 05:07:35 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: (Paul Eggert's message of "Mon, 4 May 2020 20:41:46 -0700") References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: <87imhb9gm6.fsf@news-spur.riddles.org.uk> >>>>> "Paul" == Paul Eggert writes: >>>> Or they can trivially patch the build system not to install >>>> backward zones. >>> >>> Well, there used to be a build option for that in the base system, >>> but somebody just took it out... >> >> Easy enough to put back if someone yells about it. Paul> Might make sense to put it back in (if only for compatibility Paul> with older FreeBSD systems where TZ='W-SU' gave you UTC :-). But the real point here is that we _want_ some of the backward zones - especially the ones that users may have legitimately configured with tzsetup (which reads zone.tab / zone1970.tab) in the past but which got renamed (as in the recent example of America/Godthab). The problem right now is that there isn't a way to conveniently distinguish those zones from the ones that just get in the way and cause confusion. This is why my proposal retains in the "backward" file every zone that has ever been in zone.tab. -- Andrew. From tgl at sss.pgh.pa.us Tue May 5 04:33:15 2020 From: tgl at sss.pgh.pa.us (Tom Lane) Date: Tue, 05 May 2020 00:33:15 -0400 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87imhb9gm6.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> <87imhb9gm6.fsf@news-spur.riddles.org.uk> Message-ID: <22630.1588653195@sss.pgh.pa.us> Andrew Gierth writes: > But the real point here is that we _want_ some of the backward zones - > especially the ones that users may have legitimately configured with > tzsetup (which reads zone.tab / zone1970.tab) in the past but which got > renamed (as in the recent example of America/Godthab). > The problem right now is that there isn't a way to conveniently > distinguish those zones from the ones that just get in the way and cause > confusion. This is why my proposal retains in the "backward" file every > zone that has ever been in zone.tab. It's not clear to me whether your proposal includes removal of the newly "deprecated" zones from the default build rule. If it doesn't, then this is just paper-shuffling so far as many (most?) consumers of tzdata are concerned. It gets considerably more real if the proposal is to not include the "deprecated" source file in the standard Makefile build rule. Postgres, for instance, has for some time just used whatever is in the distributed tzdata.zi file. So we'd either continue to support these zones, or not, depending on what happens in the build process for that file. I don't currently have an opinion on whether changing that would be a good or bad thing ... but as far as I could see, you didn't say what you wanted to happen. regards, tom lane From sla at ucolick.org Tue May 5 05:54:29 2020 From: sla at ucolick.org (Steve Allen) Date: Mon, 4 May 2020 22:54:29 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: <20200505055429.GA31871@ucolick.org> On Mon 2020-05-04T19:58:42-0600 Paul Gilmartin via tz hath writ: > On 2020-05-04, at 18:26:22, Andrew Gierth wrote: > > (To the best of my knowledge there are no reference clocks available to > > which one could synchronize in order to use a mean solar time, so your > > argument seems to me to support this choice.) > > > Do you mean mean solar time at some arbitrary precise longitude > or mean solar time at the Prime Meridian? If the latter, is > interpolated UT1 a close enough approximation?: > https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination UT1 is not mean solar time, but it is the quantity which is conventionally recognized as mean solar time. In 1954 Sadler recognized that by its existing convention UT (not then yet named UT1) deviates from mean solar time. https://www.ucolick.org/~sla/leapsecs/Sadler1954.pdf Seago and Seidelmann explored this much more deeply in 2013 https://www.agi.com/resources/white-papers/the-mean-solar-time-origin-of-universal-time-and-u and showed how an alternative formulation might be developed if calendar days are to continue be determined by measuring rotation of the earth. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m From tgl at sss.pgh.pa.us Tue May 5 13:43:52 2020 From: tgl at sss.pgh.pa.us (Tom Lane) Date: Tue, 05 May 2020 09:43:52 -0400 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <22630.1588653195@sss.pgh.pa.us> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> <87imhb9gm6.fsf@news-spur.riddles.org.uk> <22630.1588653195@sss.pgh.pa.us> Message-ID: <18878.1588686232@sss.pgh.pa.us> I wrote: > It's not clear to me whether your proposal includes removal of the > newly "deprecated" zones from the default build rule. After further thought I've concluded that I don't like Andrew's proposal as-presented. If some zone names are moved into a new source file, what will inevitably happen is that some platforms/ repackagers will continue to support those names, while others will not --- either through conscious choice or just by forgetting to update their build recipes. That seems like a bad situation to create. Like it or not, tzdb has created a de facto standard for the set of known zone names, and it's better for a standard to be actually standard, not subject to local whims. Recall that in the other thread Andrew referred to, FreeBSD got ragged on for being the only major platform not supporting the "backward" zones. That was justifiable IMO, and I don't think that situation should be reintroduced or magnified. Thus, I think it would be better to either do nothing, or decide that these zone names are dead, and summarily remove them altogether. While the latter option would no doubt cause some pain somewhere, it's not without precedent. I compare it to the effort not so long ago to remove undocumented zone abbreviations. That did result in some push-back, but not a huge amount ... and what's more to the point for the current discussion, downstream packagers were not given any choice in the matter. In short, I don't care hugely whether these zone names live or die; but let's either kill them off everywhere or nowhere. regards, tom lane From PaulGBoulder at AIM.com Tue May 5 14:27:33 2020 From: PaulGBoulder at AIM.com (Paul Gilmartin) Date: Tue, 5 May 2020 08:27:33 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: <9AC60D5D-DAA9-4484-800F-23D20FDDDC80@AIM.com> On 2020-05-04, at 21:16:42, Philip Paeps wrote: > > On 2020-05-05 11:00:18 (+0800), Andrew Gierth wrote: >> >> >> Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most. > > It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely). > It varies. On Linux I see numerous symlinks. (Doesn't a symlink use a disk block?) On MacOS, I see neither symlinks nor multiple directory links, but many duplicate files. -- gil From john.haxby at oracle.com Tue May 5 16:46:12 2020 From: john.haxby at oracle.com (John Haxby) Date: Tue, 5 May 2020 17:46:12 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <9AC60D5D-DAA9-4484-800F-23D20FDDDC80@AIM.com> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> <9AC60D5D-DAA9-4484-800F-23D20FDDDC80@AIM.com> Message-ID: <181014FF-D1A5-4CB6-9DA8-D640F66B9BC6@oracle.com> > On 5 May 2020, at 15:27, Paul Gilmartin via tz wrote: > > On 2020-05-04, at 21:16:42, Philip Paeps wrote: >> >> On 2020-05-05 11:00:18 (+0800), Andrew Gierth wrote: >>> >>> >>> Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most. >> >> It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely). >> > It varies. > > On Linux I see numerous symlinks. (Doesn't a symlink use a disk block?) Reasonably short symlinks are stored in the inode. Links, though, are just an entry in a directory so don't occupy any additional space unless you have a few thousand of them. jch > > On MacOS, I see neither symlinks nor multiple directory links, > but many duplicate files. Disk space is cheap :) jch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: Message signed with OpenPGP URL: From Brian.Inglis at SystematicSw.ab.ca Tue May 5 18:08:38 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Tue, 5 May 2020 12:08:38 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: <96e5d880-676c-03cf-4a59-a6556ea860df@SystematicSw.ab.ca> On 2020-05-04 21:41, Paul Eggert wrote: > On 5/4/20 8:16 PM, Philip Paeps wrote: > >> It looks like we install the files rather than links.? Or I've botched something >> on the test machine I looked at (which is not unlikely). > > If you're installing files then that should get fixed. In tzdb on my Fedora 31 > platform (ext4 filesystem with 4 KiB blocks), 'make install' creates a zoneinfo > directory that 'du' reports consumes 1800 KiB, as opposed to the 1776 KiB > consumed for the same directory with 'make BACKWARD="" install'. The 24 KiB > difference comes mostly from the five extra directories implied by 'backward' > (Brazil, Canada, Chile, Mexico, US) each of which consume 4 KiB; the rest comes > from the larger tzdata.zi file (108 vs 112 KiB allocated, due to the extra -L > lines). A number of distros seem to end up installing file copies or symbolic rather than hard links under /usr/share/zoneinfo. I created a simple shell script to check GMT link count and if not > 1, `find` all symlinks, relink symbolic as hard links, `find` all files, `sort` by size, `cmp` those of the same size, and hard `link` them if identical, with before and after summary unique and total inode, link, and file counts and sizes. For systems installing right with copies, it drops the size from three copies >4.5MB to two copies ~3.4MB; for systems installing right with symlinks, it only reduces the size of each copy by the size of the symlink paths, about 25KB/copy, but avoids the indirection access. [I became wary of tz performance, when one process on an AIX system took about 1s per naive `getenv` TZ save, `putenv` TZ set, `tzset` to load data and switch tz in a thread, and it was doing a couple of switches per transaction, depending on front end user locales. Going via the DB interface instead provided caching to speed up lookups, and minor local caching avoided lookups as much as possible.] >>>> Or they can trivially patch the build system not to install backward zones. >>> >>> Well, there used to be a build option for that in the base system, but >>> somebody just took it out... >> >> Easy enough to put back if someone yells about it. > > Might make sense to put it back in (if only for compatibility with older FreeBSD > systems where TZ='W-SU' gave you UTC :-). It would be nice to get some tzdata- alternative packages with -minimal, -tiny, -big, -full, etc. variants depending on build options, perhaps more meaningful names; similar to dict, scowl, words list packages on some distros. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From Brian.Inglis at SystematicSw.ab.ca Tue May 5 19:14:44 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Tue, 5 May 2020 13:14:44 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: On 2020-05-04 19:58, Paul Gilmartin via tz wrote: > On 2020-05-04, at 18:26:22, Andrew Gierth wrote: >> I mean that where the tzcode uses "GMT" as a default zone name or >> abbreviation in the absence of data, FreeBSD uses "UTC" (and has since >> 2004). >> e.g. with no /etc/localtime file, >> % env -u TZ date >> Tue 5 May 2020 00:00:37 UTC >> >> (To the best of my knowledge there are no reference clocks available to >> which one could synchronize in order to use a mean solar time, so your >> argument seems to me to support this choice.) >> > Do you mean mean solar time at some arbitrary precise longitude > or mean solar time at the Prime Meridian? If the latter, is > interpolated UT1 a close enough approximation?: > https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination No, as the precision of UT1 based on the Earth Rotation Angle is ms a day; UT1R has 62 smoothing terms; UT2 smoothes out seasonal variations; some variation of UT would be required to provide mean solar time at a consistent rate. NIST are still applying radio clock accuracy standards with ~ms precision, where the current norm is ~us from GPS, certainly over local LAN and even over decent remote WAN links. The older standard is adequate for MS products which require only watch-and-eyeball accuracy, but more systems are needing more accurate time. [The point may be moot, as the lawyers heading the US FCC approved the junk science from US Ligado Networks lawyers that say GNSS will not be disrupted by their terrestrial L band transmissions. Those disrupted will have to prove to US FCC lawyers that they were disrupted by US Ligado Networks transmissions. Ligado used to be LightSquared which went bankrupt when their testing proved their transmissions would disrupt GNSS. The FCC no longer requires tests, just sworn assertions from lawyers, if the lawyers approve how the physics is used!] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From sla at ucolick.org Tue May 5 21:05:08 2020 From: sla at ucolick.org (Steve Allen) Date: Tue, 5 May 2020 14:05:08 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: <20200505210508.GB19786@ucolick.org> On Tue 2020-05-05T13:14:44-0600 Brian Inglis hath writ: > On 2020-05-04 19:58, Paul Gilmartin via tz wrote: > > On 2020-05-04, at 18:26:22, Andrew Gierth wrote: > >> (To the best of my knowledge there are no reference clocks available to > >> which one could synchronize in order to use a mean solar time, so your > >> argument seems to me to support this choice.) > >> > > Do you mean mean solar time at some arbitrary precise longitude > > or mean solar time at the Prime Meridian? If the latter, is > > interpolated UT1 a close enough approximation?: > > https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination > > No, as the precision of UT1 based on the Earth Rotation Angle is ms a day; UT1R > has 62 smoothing terms; UT2 smoothes out seasonal variations; some variation of > UT would be required to provide mean solar time at a consistent rate. > NIST are still applying radio clock accuracy standards with ~ms precision, where > the current norm is ~us from GPS, certainly over local LAN and even over decent > remote WAN links. The UK radio broadcast time signals stopped providing GMT in 1953. Starting then they transmitted Provisional Uniform Time, PUT, which was their own forerunner version of UT2. The US radio broadcast time signals made similar changes around then. The USNO version of uniform time scale had names like N3c. So since the 1950s there has been no real-time source of mean solar time, only quartz and cesium clock time adjusted to follow that. > The older standard is adequate for MS products which require only > watch-and-eyeball accuracy, but more systems are needing more accurate time. Different sources of radio broadcast time signals did not agree to within 1 ms until 1960 when the US and UK began to coordinate their transmissions using cesium. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m From jhawk at alum.mit.edu Tue May 5 01:00:17 2020 From: jhawk at alum.mit.edu (John Hawkinson) Date: Mon, 4 May 2020 21:00:17 -0400 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> Message-ID: <20200505010017.GQ3070@alum.mit.edu> Paul Eggert wrote on Mon, 4 May 2020 at 20:46:52 EDT in <7949485f-7efc-5590-ac50-a12dfd4c7718 at cs.ucla.edu>: > Getting back to the main point, I'm not sure it's worth deprecating > links like 'US/Pacific' any time soon, as so many people use them I would strongly object to such deprecation. I realize we've set ourselves on such a path in a historical decision I disagree with, and that there's a desire not to relitigate it, but those links make a logical sense that should not be ignored. Leave those alone, please. Conservatism cautions against unnecessary churn. -- jhawk at alum.mit.edu John Hawkinson > and their cost is not great. It might be worth coming up with some > division of the existing 'backward' file (e.g., recently-backward > names vs older-backward names), although I'm not sure what that > would look like. I suppose we could have a comment associated with > each name saying when it became backward, though that'd increase > maintenance hassle. From paul at ganssle.io Wed May 13 18:19:23 2020 From: paul at ganssle.io (Paul Ganssle) Date: Wed, 13 May 2020 14:19:23 -0400 Subject: [tz] Proper (stable) way to list installed time zones? Message-ID: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> As part of the implementation of IANA time zone support in the Python standard library (which is now accepted for inclusion in Python 3.9 ? many thanks to those who commented on the original proposal), I realized that likely a common feature request is to get the list of time zones installed in the system. I have a candidate implementation for this, which basically walks each potential install directory (there's a "time zone search path" equivalent to PATH) and populates a list of every file installed there which starts with the `TZif` magic string. The problem I'm running into is that tzcode installs `posix/` and `right/` folders, so for each entry in zoneinfo, I get three entries: "Africa/Abidjan", "posix/Africa/Abidjan" and "right/Africa/Abidjan". I'm also seeing a `posixrules` zone in the zoneinfo root. My questions are: 1. Is there a better source for the list of installed time zones (leaving aside `tzdata.zi`, which I don't think I can count on to exist in all environments). 2. Is there any stable and standard way to distinguish between proper zones and other things that are also zone files like posixrules and right/ and posix/? In my own redistribution of the data, I populate a list of zones from `make zonenames`, which I note does /not/ include posix/, right/ or posixrules, but I don't think that information is included in standard distributions of zoneinfo. The closest I can find is `zone1970.tab` and `zone.tab` (which I think is not even always included), and that appears to be only a subset of the output of `make zonenames`. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tim at timtimeonline.com Thu May 14 01:54:57 2020 From: tim at timtimeonline.com (Tim Parenti) Date: Wed, 13 May 2020 21:54:57 -0400 Subject: [tz] Removing systemv, pacificnew, Rule TYPEs, zic -y Message-ID: I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references. Of course, I was only looking at systemv in the first place because I'd also recalled that we're still distributing the pacificnew file, which has caused some confusion every so often and has likewise generally outlived its usefulness. This led me to the related file yearistype.sh, which is also unused, except as a default script to pass to the Makefile to process the TYPE field of Rule lines. Given that the TYPE field hasn't been used by tzdata since 2000f and has been more formally deprecated since 2015f, the whole unused feature is ripe for "spring cleaning". The attached proposed patch 0002 completely drops support for the TYPE field (marking it reserved for compatibility purposes) and causes non-trivial use of the field or use of zic's -y option to error (instead of warning as it has since 2017c). It also removes the pacificnew and yearistype.sh files that are no longer needed and updates documentation accordingly. I don't presently foresee any need to repurpose the nullified field down the road, but this is the next step in allowing us to "reclaim" it in the event that such a need should arise in the future. -- Tim Parenti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-obsolete-file-systemv.patch Type: application/octet-stream Size: 4344 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Drop-support-for-zic-y-Rule-TYPEs-pacificnew.patch Type: application/octet-stream Size: 75235 bytes Desc: not available URL: From eggert at cs.ucla.edu Thu May 14 02:13:37 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Wed, 13 May 2020 19:13:37 -0700 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> Message-ID: <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> On 5/13/20 11:19 AM, Paul Ganssle wrote: > The problem I'm running into is that tzcode installs `posix/` and > `right/` folders, so for each entry in zoneinfo, I get three entries: > "Africa/Abidjan", "posix/Africa/Abidjan" and "right/Africa/Abidjan". I'm > also seeing a `posixrules` zone in the zoneinfo root. The posix/* entries are duplicates are the main ones, and the right/* entries are with leap seconds (which aren't normally used). The posixrules is for when one uses a nonconforming TZ string like TZ='EST5EDT'. > 1. Is there a better source for the list of installed time zones > (leaving aside `tzdata.zi`, which I don't think I can count on to exist > in all environments). That depends on what you want the list for. If you want every value V such that TZ='V' works via reading files, you've got the right list. If you want every value V such that TZ='V' works, then you have just a subset since POSIX-style Vs are not taken from files. If you want a shorter list (which makes sense), you can omit the posix/* and right/* and posixrules entries. > 2. Is there any stable and standard way to distinguish between proper > zones and other things that are also zone files like posixrules and > right/ and posix/? Depends on what you mean by 'proper'. :-) 'make zonenames' should be equivalent to looking in tzdata.zi, because that's what 'make zonenames' does. And that should be equivalent to the "shorter list" mentioned above. > The closest I can find is `zone1970.tab` and > `zone.tab` (which I think is not even always included), and that appears > to be only a subset of the output of `make zonenames`. Yup. The method I'd suggest is tzdata.zi if available, or the "shorter list" mentioned above, whichever's faster. This is because zone1970.tab and zone.tab don't list some of the duplicates, and some users like the duplicates. If you also want the leap-second entries, you'll need the right/* entries though. From paul at ganssle.io Fri May 15 14:39:04 2020 From: paul at ganssle.io (Paul Ganssle) Date: Fri, 15 May 2020 10:39:04 -0400 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> Message-ID: This is very tough, because there are a lot of plausible subsets that someone could want, and there are not good names for them all (nor, it seems, do they all have a foolproof method of detection). I'd say one could easily want: 1. Every valid value for key that doesn't raise an error when you call ZoneInfo(key) 2. All the values found in tzdata.zi 3. The intersection of the values found in tzdata.zi and the keys that actually exist on disk 4. All the values from zone.tab and/or zone1970.tab 5. The intersection of #4 and all the keys that actually exist on disk 6. #4 or #5, but also including "UTC" (and possibly the fixed-offset zones like Etc/GMT+5 or whatever) My inclination would be to compile a list of zones annotated with each entry's membership in each of these groups and let the end user filter as desired, but that's slightly complicated by the fact that almost all the indicators other than #1 may be manipulated by the install mechanism, and it becomes hard to distinguish between "not present in tzdata.zi" and "tzdata.zi not shipped". That said, it sounds to me like we can probably safely say that it is unlikely that we won't have to special case any names of folders or files /other/ than posixrules, posix/ and right/ for the foreseeable future and that if distros rename those files but still put them under the zoneinfo root, that's probably safely considered a bug in the distro. I'm still mildly uncertain as to whether it's possible that tzdata.zi might have more zones than are actually installed (for example if a distro doesn't install anything in backward or antarctica for some reason). With regards to this: > If you also want the leap-second entries, you'll need the right/* entries though. Is it always the case that the right/ and posix/ trees are identical to the primary tree? If so, it's reasonable to leave right/ and posix/ out of the listings and users can know that if they want the right/* entries, they can just prepend "right/" to any given key. Best, Paul On 5/15/20 9:43 AM, Filipe La?ns wrote: > On Wed, 2020-05-13 at 19:13 -0700, Paul Eggert wrote: >> Yup. The method I'd suggest is tzdata.zi if available, or the "shorter list" >> mentioned above, whichever's faster. This is because zone1970.tab and zone.tab >> don't list some of the duplicates, and some users like the duplicates. >> >> If you also want the leap-second entries, you'll need the right/* entries though. > I am thinking the best approach should be reading tzdata.zi when > available, and potentially fallback to ignoring posix/* and > right/* and posixrules. I am not sure about this last one though, for > reasons outlined in the PR. What do you think Paul (G.)? > > Filipe La?ns -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From eggert at cs.ucla.edu Fri May 15 19:52:35 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 15 May 2020 12:52:35 -0700 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> Message-ID: <2f73c604-0592-224b-7f57-f065617faa87@cs.ucla.edu> On 5/15/20 7:39 AM, Paul Ganssle wrote: > I'd say one > could easily want: > > 1. Every valid value for key that doesn't raise an error when you call > ZoneInfo(key) Does ZoneInfo operate by looking for an actual file, or by setting TZ='key' and seeing whether that works? If the latter, there are many keys that are not listed anywhere because they're specified by POSIX. A simple example is TZ='MST7' which is a valid POSIX key and which is commonly used, but for which there is no file or tzdata.zi entry. I looked at PEP 615 and didn't see any mention of the issue of POSIX-specified TZ settings. > I'm still mildly uncertain as to whether it's possible that tzdata.zi > might have more zones than are actually installed (for example if a > distro doesn't install anything in backward or antarctica for some reason). In the reference implementation, the zones are installed from tzdata.zi so the lists should be identical there. > Is it always the case that the right/ and posix/ trees are identical to > the primary tree? Yes, in the reference implementation. From lains at archlinux.org Fri May 15 13:43:05 2020 From: lains at archlinux.org (Filipe =?ISO-8859-1?Q?La=EDns?=) Date: Fri, 15 May 2020 14:43:05 +0100 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> Message-ID: On Wed, 2020-05-13 at 19:13 -0700, Paul Eggert wrote: > Yup. The method I'd suggest is tzdata.zi if available, or the "shorter list" > mentioned above, whichever's faster. This is because zone1970.tab and zone.tab > don't list some of the duplicates, and some users like the duplicates. > > If you also want the leap-second entries, you'll need the right/* entries though. I am thinking the best approach should be reading tzdata.zi when available, and potentially fallback to ignoring posix/* and right/* and posixrules. I am not sure about this last one though, for reasons outlined in the PR. What do you think Paul (G.)? Filipe La?ns -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From Brian.Inglis at SystematicSw.ab.ca Fri May 15 22:25:25 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Fri, 15 May 2020 16:25:25 -0600 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: <2f73c604-0592-224b-7f57-f065617faa87@cs.ucla.edu> References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> <2f73c604-0592-224b-7f57-f065617faa87@cs.ucla.edu> Message-ID: <90c5c29c-9cf8-46ec-1006-d6251ffcd773@SystematicSw.ab.ca> On 2020-05-15 13:52, Paul Eggert wrote: > On 5/15/20 7:39 AM, Paul Ganssle wrote: >> I'd say one >> could easily want: >> >> 1. Every valid value for key that doesn't raise an error when you call >> ZoneInfo(key) > > Does ZoneInfo operate by looking for an actual file, or by setting TZ='key' and > seeing whether that works? If the latter, there are many keys that are not > listed anywhere because they're specified by POSIX. A simple example is > TZ='MST7' which is a valid POSIX key and which is commonly used, but for which > there is no file or tzdata.zi entry. I looked at PEP 615 and didn't see any > mention of the issue of POSIX-specified TZ settings. > >> I'm still mildly uncertain as to whether it's possible that tzdata.zi >> might have more zones than are actually installed (for example if a >> distro doesn't install anything in backward or antarctica for some reason). > > In the reference implementation, the zones are installed from tzdata.zi so the > lists should be identical there. > >> Is it always the case that the right/ and posix/ trees are identical to >> the primary tree? > > Yes, in the reference implementation. For every zone in the sources, try the following from your tzdata directory: $ awk ' /^Zone/ { print $2, "Zone", FILENAME } /^Link/ { print $3, "Link", FILENAME, $2 } /^[^#]/ && FILENAME ~ /zone[^.]*\.tab/ { print $3, "Tab", FILENAME, $1, $2 } ' africa antarctica asia australasia backward backzone etcetera \ europe factory northamerica pacificnew solar8[7-9] systemv \ usno1988 usno1989 usno1989a usno199[578] zone.tab zone1970.tab | \ sort -dfuk1,1 you can drop the sort -u or the sort command to see the selected data, or drop the extra fields to just get the zone names - 586 unique entries total possible. If I missed some selection source or criterion please post on the list. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From tim at timtimeonline.com Sun May 17 17:55:16 2020 From: tim at timtimeonline.com (Tim Parenti) Date: Sun, 17 May 2020 13:55:16 -0400 Subject: [tz] Updating zic.c to further match Link line field names Message-ID: In working on my latest proposed patch, I also noticed an outdated error message in zic.c which referred to the FROM field of a Link line. We had updated these field names in comments and documentation in release 2014g to be more descriptive and readily understandable like the parameters of 'ln': https://github.com/eggert/tz/commit/78e3924ea43079a0f3333677a728e0f0ed679cd3 The attached proposed patch further updates the zic.c code to more consistently use these new names throughout. This mostly affects the naming of parameters and locals, but a few macros and struct fields are also updated for consistency. -- Tim Parenti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Further-update-code-to-match-Link-line-field-names.patch Type: application/octet-stream Size: 8822 bytes Desc: not available URL: From gkssarma59 at gmail.com Wed May 20 11:32:25 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Wed, 20 May 2020 17:02:25 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: Message-ID: Hello team, According to the latest 2020a tz update: Canada's Yukon, represented by America/Whitehorse and America/Dawson, advanced to -07 year-round, beginning with its spring-forward transition on 2020-03-08, and will not fall back on 2020-11-01. We have written a test cases like below for canada yukon timezone. We imported new 2020a tz into our environment. Our code seems correct but test cases are failing. So we found that there is wrong in Iana tz side. Please check and correct us. This is the below code we have written. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on 2nd nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); -------> here we are getting error: java.lang.AssertionError: expected:<-7> but was:<-8> } The above test case according to your update (will not fall back on 2020-11-01) is correct. But test case is failing. Could you please clarify us that is there anything wrong from IANA tz. If not how can i write my test case according to that? Regards, Sundar On Wed, May 20, 2020 at 3:51 PM wrote: > Welcome to the tz at iana.org mailing list! > > > --- > > NOTE WELL > > Any submission to the IETF intended by the Contributor for publication > as all or part of an IETF Internet-Draft or RFC and any statement made > within the context of an IETF activity is considered an "IETF > Contribution". Such statements include oral statements in IETF > sessions, as well as written and electronic communications made at any > time or place, which are addressed to: > > * The IETF plenary session * The IESG, or any member thereof on behalf > of the IESG * Any IETF mailing list, including the IETF list itself, > any working group or design team list, or any other list functioning > under IETF auspices * Any IETF working group or portion thereof * Any > Birds of a Feather (BOF) session * The IAB or any member thereof on > behalf of the IAB * The RFC Editor or the Internet-Drafts function * > All IETF Contributions are subject to the rules of RFC 5378 and RFC > 3979 (updated by RFC 4879). > > Statements made outside of an IETF session, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not IETF Contributions in the context > of this notice. > > Please consult RFC 5378 and RFC 3979 for details. > > A participant in any IETF activity is deemed to accept all IETF rules > of process, as documented in Best Current Practices RFCs and IESG > Statements. > > A participant in any IETF activity acknowledges that written, audio > and video records of meetings may be made and may be available to the > public. > > --- > > To post to this list, send your email to: > > tz at iana.org > > General information about the mailing list is at: > > https://mm.icann.org/mailman/listinfo/tz > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://mm.icann.org/mailman/options/tz/gkssarma59%40gmail.com > > You can also make such adjustments via email by sending a message to: > > tz-request at iana.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > Gks59 at smu > > Normally, Mailman will remind you of your iana.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Wed May 20 15:17:29 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Wed, 20 May 2020 09:17:29 -0600 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: Message-ID: <674f650a-6b98-0e28-8b60-464a45639cdf@SystematicSw.ab.ca> On 2020-05-20 05:32, Sundar Sarma wrote: > According to the latest 2020a tz update: Canada's Yukon, represented by > America/Whitehorse and > ? ? America/Dawson, advanced to -07 year-round, beginning with its > ? ? spring-forward transition on 2020-03-08, and will not fall back on > ? ? 2020-11-01. > We have written a test cases like below for canada yukon timezone. We imported > new 2020a tz into our environment. > Our code seems correct but test cases are failing. So we found that there is > wrong in Iana tz side. > Please check and correct us. This is the below code we have written. > @Test > ? ? public void doesNotFallBackToMinus8InDawsonNovember2020() { > ? ? ? ? DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); > ? ? ? ? Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on > 2nd nov 00:00:00 > ? ? ? ? ? ? ? ? .withLaterOffsetAtOverlap() > ? ? ? ? ? ? ? ? .toInstant(); > ? ? ? ? Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st > nov 00:00:00 > ? ? ? ? ? ? ? ? .withLaterOffsetAtOverlap() > ? ? ? ? ? ? ? ? .toInstant(); > ? ? ? ? long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); > ? ? ? ? int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); > ? ? ? ? long offsetOnDay = timezone.getOffset(day.getMillis()); > ? ? ? ? int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); > ? ? ? ? assertEquals(hoursOnDay, dayAfterHours); ?-------> ?here we are getting > error: java.lang.AssertionError: expected:<-7> but was:<-8> > ? ? } > The above test case according to your update (will not fall back on 2020-11-01) > is correct. But test case is failing. > Could you please clarify us that is there anything wrong from IANA tz. > If not how can i write my test case according to that?? For a start, you must always take account of the summer transition times forward and back. Across Canada, times change at Sunday 02:00 local time: in March, as each time zone hits 02:00, it becomes 03:00; in November, as each time zone hits 02:00, it becomes 01:00: $ zdump -Vc2020,2021 Canada/Mountain | sed 's/\(Sun\).*\1/\1/' Canada/Mountain Sun Mar 8 01:59:59 2020 MST isdst=0 gmtoff=-25200 Canada/Mountain Sun Mar 8 03:00:00 2020 MDT isdst=1 gmtoff=-21600 Canada/Mountain Sun Nov 1 01:59:59 2020 MDT isdst=1 gmtoff=-21600 Canada/Mountain Sun Nov 1 01:00:00 2020 MST isdst=0 gmtoff=-25200 so to be sure, you need to check on or after each transition, as you will have ambiguous times on Sunday in March between 01:00 and 02:00, and in November between 02:00 and 03:00. In both cases, you could check on or after Sun 03:00. Checking at 12:00 noon is often chosen to be safe regardless of actual transition times, which could vary from 00:00 to 06:00. Similarly, checks are often done on December 31 and June 30 to avoid being near any northern or southern hemisphere transition dates. However in recent years Islamic countries have started to reset summer time changes during Ramadan, which can occur any time in the Gregorian calendar. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From gkssarma59 at gmail.com Wed May 20 16:55:12 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Wed, 20 May 2020 22:25:12 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <674f650a-6b98-0e28-8b60-464a45639cdf@SystematicSw.ab.ca> References: <674f650a-6b98-0e28-8b60-464a45639cdf@SystematicSw.ab.ca> Message-ID: Is Yukon part of Canada/Mountain? Regards, Sundar On Wed, May 20, 2020 at 8:47 PM Brian Inglis < Brian.Inglis at systematicsw.ab.ca> wrote: > On 2020-05-20 05:32, Sundar Sarma wrote: > > According to the latest 2020a tz update: Canada's Yukon, represented by > > America/Whitehorse and > > America/Dawson, advanced to -07 year-round, beginning with its > > spring-forward transition on 2020-03-08, and will not fall back on > > 2020-11-01. > > We have written a test cases like below for canada yukon timezone. We > imported > > new 2020a tz into our environment. > > Our code seems correct but test cases are failing. So we found that > there is > > wrong in Iana tz side. > > Please check and correct us. This is the below code we have written. > > @Test > > public void doesNotFallBackToMinus8InDawsonNovember2020() { > > DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); > > Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, > timezone)-------> on > > 2nd nov 00:00:00 > > .withLaterOffsetAtOverlap() > > .toInstant(); > > Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> > on 1 st > > nov 00:00:00 > > .withLaterOffsetAtOverlap() > > .toInstant(); > > long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); > > int dayAfterHours = (int) > TimeUnit.MILLISECONDS.toHours(dayAfterOffset); > > long offsetOnDay = timezone.getOffset(day.getMillis()); > > int hoursOnDay = (int) > TimeUnit.MILLISECONDS.toHours(offsetOnDay); > > assertEquals(hoursOnDay, dayAfterHours); -------> here we are > getting > > error: java.lang.AssertionError: expected:<-7> but was:<-8> > > } > > The above test case according to your update (will not fall back on > 2020-11-01) > > is correct. But test case is failing. > > Could you please clarify us that is there anything wrong from IANA tz. > > If not how can i write my test case according to that? > > For a start, you must always take account of the summer transition times > forward > and back. > Across Canada, times change at Sunday 02:00 local time: in March, as each > time > zone hits 02:00, it becomes 03:00; in November, as each time zone hits > 02:00, it > becomes 01:00: > > $ zdump -Vc2020,2021 Canada/Mountain | sed 's/\(Sun\).*\1/\1/' > Canada/Mountain Sun Mar 8 01:59:59 2020 MST isdst=0 gmtoff=-25200 > Canada/Mountain Sun Mar 8 03:00:00 2020 MDT isdst=1 gmtoff=-21600 > Canada/Mountain Sun Nov 1 01:59:59 2020 MDT isdst=1 gmtoff=-21600 > Canada/Mountain Sun Nov 1 01:00:00 2020 MST isdst=0 gmtoff=-25200 > > so to be sure, you need to check on or after each transition, as you will > have > ambiguous times on Sunday in March between 01:00 and 02:00, and in November > between 02:00 and 03:00. > In both cases, you could check on or after Sun 03:00. > Checking at 12:00 noon is often chosen to be safe regardless of actual > transition times, which could vary from 00:00 to 06:00. > Similarly, checks are often done on December 31 and June 30 to avoid being > near > any northern or southern hemisphere transition dates. > However in recent years Islamic countries have started to reset summer time > changes during Ramadan, which can occur any time in the Gregorian calendar. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at timtimeonline.com Wed May 20 19:22:05 2020 From: tim at timtimeonline.com (Tim Parenti) Date: Wed, 20 May 2020 15:22:05 -0400 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: <674f650a-6b98-0e28-8b60-464a45639cdf@SystematicSw.ab.ca> Message-ID: On Wed, 20 May 2020 at 12:55, Sundar Sarma wrote: > Is Yukon part of Canada/Mountain? > No; Canada/Mountain is a link in the 'backward' file to America/Edmonton which is only present for backwards compatibility and should generally not be used. Splits and differences like this underline the importance of using the correct and supported identifiers wherever possible. -- Tim Parenti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eggert at cs.ucla.edu Wed May 20 22:01:32 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Wed, 20 May 2020 15:01:32 -0700 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: Message-ID: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> On 5/20/20 4:32 AM, Sundar Sarma wrote: > The above test case according to your update (will not fall back on > 2020-11-01) is correct. But test case is failing. My guess is that you didn't propagate the data into Java. Java doesn't use tzdata's TZif files directly; it builds and installs its own copy of the files and uses that. If Java's copy is obsolete then Java programs will report obsolete results. For more about this see and look for "Oracle Java". You can test this by running the shell command: zdump -v -c 2020,2021 America/Dawson If older tzdata is installed you'll see this: $ zdump -v -c 2020,2022 America/Dawson America/Dawson -9223372036854775808 = NULL America/Dawson -9223372036854689408 = NULL America/Dawson Sun Mar 8 09:59:59 2020 UTC = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UTC = Sun Mar 8 03:00:00 2020 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 1 08:59:59 2020 UTC = Sun Nov 1 01:59:59 2020 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 1 09:00:00 2020 UTC = Sun Nov 1 01:00:00 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 14 09:59:59 2021 UTC = Sun Mar 14 01:59:59 2021 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 14 10:00:00 2021 UTC = Sun Mar 14 03:00:00 2021 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 7 08:59:59 2021 UTC = Sun Nov 7 01:59:59 2021 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 7 09:00:00 2021 UTC = Sun Nov 7 01:00:00 2021 PST isdst=0 gmtoff=-28800 America/Dawson 9223372036854689407 = NULL America/Dawson 9223372036854775807 = NULL with transitions continuing this fall and next year. In tzdata 2020a you'll see this: $ zdump -v -c 2020,2022 America/Dawson America/Dawson -9223372036854775808 = NULL America/Dawson -9223372036854689408 = NULL America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 MST isdst=0 gmtoff=-25200 America/Dawson 9223372036854689407 = NULL America/Dawson 9223372036854775807 = NULL with transitions stopping after March of this year, and Yukon observing MST now. If you see the latter output then your tzdata is up-to-date; if Java is reporting incorrect results in this area then the problem has something to do with the Java installation, which is downstream from us. From eggert at cs.ucla.edu Wed May 20 22:03:45 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Wed, 20 May 2020 15:03:45 -0700 Subject: [tz] Tim Parenti as backup TZ Coordinator? Message-ID: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Tim Parenti's recent emails to the list reminded me that I'd long been meaning to nominate him to be my backup as TZ Coordinator. We should have a backup in case I am no longer available due to retirement or whatever, not that I'm planning to retire any time soon. I would like to start by giving him commit privileges to the development repository on GitHub, so that his contributions can become part of releases more easily. Tim has been a longtime and substantial contributor to tzdb, as evidenced by his detailed and careful patches. Although he's mostly worked in the tzdata area, he's also proficient on the code side, as his recent patch proposals demonstrate. He and I have corresponded by email about this and he's indicated his willingness to take on the responsibility. I'd appreciate reactions to Tim's offer to be backup; please respond within the next week. From Brian.Inglis at SystematicSw.ab.ca Wed May 20 22:17:24 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Wed, 20 May 2020 16:17:24 -0600 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <7b854b3f-66cd-2200-9cfb-52bcd3ccf2ac@SystematicSw.ab.ca> On 2020-05-20 16:03, Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. > I would like to start by giving him commit privileges to the development > repository on GitHub, so that his contributions can become part of releases > more easily. > I'd appreciate reactions to Tim's offer to be backup; please respond within > the next week. ++ From murch at fastmail.com Wed May 20 22:20:02 2020 From: murch at fastmail.com (Ken Murchison) Date: Wed, 20 May 2020 18:20:02 -0400 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: +1 On 5/20/20 6:03 PM, Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. We should > have a backup in case I am no longer available due to retirement or > whatever, not that I'm planning to retire any time soon. I would like > to start by giving him commit privileges to the development repository > on GitHub, so that his contributions can become part of releases more > easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as > his recent patch proposals demonstrate. He and I have corresponded by > email about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From philip at trouble.is Thu May 21 06:03:08 2020 From: philip at trouble.is (Philip Paeps) Date: Thu, 21 May 2020 14:03:08 +0800 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <6EC83656-FA82-40DB-977C-E124FA94E4A8@trouble.is> On 2020-05-21 06:03:45 (+0800), Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. We should > have a backup in case I am no longer available due to retirement or > whatever, not that I'm planning to retire any time soon. I would like > to start by giving him commit privileges to the development repository > on GitHub, so that his contributions can become part of releases more > easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as > his recent patch proposals demonstrate. He and I have corresponded by > email about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. +1 Great idea. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From alanp at snowmoose.com Thu May 21 06:09:44 2020 From: alanp at snowmoose.com (Alan Perry) Date: Wed, 20 May 2020 23:09:44 -0700 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: On 5/20/20 3:03 PM, Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. We should > have a backup in case I am no longer available due to retirement or > whatever, not that I'm planning to retire any time soon. I would like > to start by giving him commit privileges to the development repository > on GitHub, so that his contributions can become part of releases more > easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as > his recent patch proposals demonstrate. He and I have corresponded by > email about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. I haven't actually worked with tzcode or tzdata in over 15 years, but it is a topic that still interests me, so I am still here. If my opinion counts for anything, +1 alan From guy at alum.mit.edu Thu May 21 06:53:15 2020 From: guy at alum.mit.edu (Guy Harris) Date: Wed, 20 May 2020 23:53:15 -0700 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <54DA9284-9CCE-481A-A120-31F0DA36CA68@alum.mit.edu> On May 20, 2020, at 3:03 PM, Paul Eggert wrote: > I'd appreciate reactions to Tim's offer to be backup +1 From clive at davros.org Thu May 21 06:33:27 2020 From: clive at davros.org (Clive D.W. Feather) Date: Thu, 21 May 2020 07:33:27 +0100 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <20200521063327.GB31931@davros.org> Paul Eggert said: > I'd appreciate > reactions to Tim's offer to be backup; please respond within the next week. I don't have any specific opinions about Tim, but succession planning is a good idea and I'm glad to see it's happening here. -- Clive D.W. Feather | If you lie to the compiler, Email: clive at davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 From gkssarma59 at gmail.com Thu May 21 12:39:33 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Thu, 21 May 2020 18:09:33 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> Message-ID: Finally, could you please confirm that is there anything wrong in my code? Still i did not understand why this test case is failing with new 2020a tz. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone) .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone) .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); } On Thu, May 21, 2020 at 3:31 AM Paul Eggert wrote: > On 5/20/20 4:32 AM, Sundar Sarma wrote: > > The above test case according to your update (will not fall back on > > 2020-11-01) is correct. But test case is failing. > > My guess is that you didn't propagate the data into Java. Java doesn't > use tzdata's TZif files directly; it builds and installs its own copy of > the files and uses that. If Java's copy is obsolete then Java programs > will report obsolete results. For more about this see > and look for "Oracle > Java". > > You can test this by running the shell command: > > zdump -v -c 2020,2021 America/Dawson > > If older tzdata is installed you'll see this: > > $ zdump -v -c 2020,2022 America/Dawson > America/Dawson -9223372036854775808 = NULL > America/Dawson -9223372036854689408 = NULL > America/Dawson Sun Mar 8 09:59:59 2020 UTC = Sun Mar 8 01:59:59 2020 > PST isdst=0 gmtoff=-28800 > America/Dawson Sun Mar 8 10:00:00 2020 UTC = Sun Mar 8 03:00:00 2020 > PDT isdst=1 gmtoff=-25200 > America/Dawson Sun Nov 1 08:59:59 2020 UTC = Sun Nov 1 01:59:59 2020 > PDT isdst=1 gmtoff=-25200 > America/Dawson Sun Nov 1 09:00:00 2020 UTC = Sun Nov 1 01:00:00 2020 > PST isdst=0 gmtoff=-28800 > America/Dawson Sun Mar 14 09:59:59 2021 UTC = Sun Mar 14 01:59:59 2021 > PST isdst=0 gmtoff=-28800 > America/Dawson Sun Mar 14 10:00:00 2021 UTC = Sun Mar 14 03:00:00 2021 > PDT isdst=1 gmtoff=-25200 > America/Dawson Sun Nov 7 08:59:59 2021 UTC = Sun Nov 7 01:59:59 2021 > PDT isdst=1 gmtoff=-25200 > America/Dawson Sun Nov 7 09:00:00 2021 UTC = Sun Nov 7 01:00:00 2021 > PST isdst=0 gmtoff=-28800 > America/Dawson 9223372036854689407 = NULL > America/Dawson 9223372036854775807 = NULL > > with transitions continuing this fall and next year. In tzdata 2020a > you'll see this: > > $ zdump -v -c 2020,2022 America/Dawson > America/Dawson -9223372036854775808 = NULL > America/Dawson -9223372036854689408 = NULL > America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 > PST isdst=0 gmtoff=-28800 > America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 > MST isdst=0 gmtoff=-25200 > America/Dawson 9223372036854689407 = NULL > America/Dawson 9223372036854775807 = NULL > > with transitions stopping after March of this year, and Yukon observing > MST now. If you see the latter output then your tzdata is up-to-date; if > Java is reporting incorrect results in this area then the problem has > something to do with the Java installation, which is downstream from us. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.h.deckers at googlemail.com Thu May 21 13:09:47 2020 From: michael.h.deckers at googlemail.com (Michael H Deckers) Date: Thu, 21 May 2020 13:09:47 +0000 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> Message-ID: <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> ?? On 2020-05-21 12:39, Sundar Sarma wrote: > Still i did not understand why this test case is failing with new 2020a tz. ?? The version of the IANA database installed in the operating ?? system may well differ from the version used by Java.time. ?? The latter can be determined with the method ??????? ZoneRulesProvider.getVersions?( String zoneId ). ?? which gives the version used by Java. ?? HTH. ?? Michael Deckers. From patsy at redhat.com Thu May 21 13:28:15 2020 From: patsy at redhat.com (Patsy Griffin) Date: Thu, 21 May 2020 09:28:15 -0400 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: +1 On Wed, May 20, 2020 at 6:04 PM Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. We should > have a backup in case I am no longer available due to retirement or > whatever, not that I'm planning to retire any time soon. I would like to > start by giving him commit privileges to the development repository on > GitHub, so that his contributions can become part of releases more easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as his > recent patch proposals demonstrate. He and I have corresponded by email > about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at whooppee.com Thu May 21 13:59:39 2020 From: paul at whooppee.com (Paul Goyette) Date: Thu, 21 May 2020 06:59:39 -0700 (PDT) Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: On Wed, May 20, 2020 at 6:04 PM Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long > been meaning to nominate him to be my backup as TZ Coordinator. We > should have a backup in case I am no longer available due to > retirement or whatever, not that I'm planning to retire any time soon. > I would like to start by giving him commit privileges to the > development repository on GitHub, so that his contributions can become > part of releases more easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as > his recent patch proposals demonstrate. He and I have corresponded by > email about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. Another +1 from me, FWIW. +--------------------+--------------------------+-----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--------------------+--------------------------+-----------------------+ From gkssarma59 at gmail.com Thu May 21 15:06:04 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Thu, 21 May 2020 20:36:04 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: after i run this code ZoneRulesProvider.getVersions( String zoneId ). i got below output {2016a=ZoneRules[currentStandardOffset=-08:00]} But in readme file of tzadata, Generated by Gradle I am getting below verison. Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz On Thu, May 21, 2020 at 6:39 PM Michael H Deckers < michael.h.deckers at googlemail.com> wrote: > > On 2020-05-21 12:39, Sundar Sarma wrote: > > > > Still i did not understand why this test case is failing with new 2020a > tz. > > > The version of the IANA database installed in the operating > system may well differ from the version used by Java.time. > The latter can be determined with the method > ZoneRulesProvider.getVersions?( String zoneId ). > which gives the version used by Java. > > HTH. > > Michael Deckers. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Thu May 21 16:18:41 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Thu, 21 May 2020 10:18:41 -0600 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: <6764db79-3f34-f3ab-5ae6-768714b2e1a3@SystematicSw.ab.ca> On 2020-05-21 07:09, Michael H Deckers via tz wrote: > > ?? On 2020-05-21 12:39, Sundar Sarma wrote: > > >> Still i did not understand why this test case is failing with new 2020a tz. > > > ?? The version of the IANA database installed in the operating > ?? system may well differ from the version used by Java.time. > ?? The latter can be determined with the method > ??????? ZoneRulesProvider.getVersions?( String zoneId ). > ?? which gives the version used by Java. >From Google and SO, with recent versions, you can do: $ jshell <<< \ 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' | Welcome to JShell -- Version 11.0.7 | For an introduction type: /help intro jshell> System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); [2019c] jshell> $ *OR* $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat /usr/lib/jvm/java-1.11.0-openjdk-i386/lib/tzdb.dat:TZDB2019c /usr/lib/jvm/java-11-openjdk-i386/lib/tzdb.dat:TZDB2019c what is actually matched is: $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat | cat -A /usr/lib/jvm/java-1.11.0-openjdk-i386/lib/tzdb.dat:^A^@^DTZDB^@^A^@^E2019c$ /usr/lib/jvm/java-11-openjdk-i386/lib/tzdb.dat:^A^@^DTZDB^@^A^@^E2019c$ so there's a code and a byte count and some zeros or nulls, so you could dump just those: $ for dat in /usr/lib/jvm/*/lib/tzdb.dat do echo $dat: head -n1 $dat | cut -c12-16 done /usr/lib/jvm/java-1.11.0-openjdk-i386/lib/tzdb.dat: 2019c /usr/lib/jvm/java-11-openjdk-i386/lib/tzdb.dat: 2019c *OR* equivalents on other systems e.g. for Oracle it should be something like: $ grep -ao '^javazm.....tzdata[12][90][0-9][0-9][a-z]' \ $JAVA_HOME/jre/lib/zi/ZoneInfoMappings *OR* $ head -n1 $JAVA_HOME/jre/lib/zi/ZoneInfoMappings | cut -c18-22 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From eggert at cs.ucla.edu Thu May 21 20:33:41 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 21 May 2020 13:33:41 -0700 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <6764db79-3f34-f3ab-5ae6-768714b2e1a3@SystematicSw.ab.ca> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <6764db79-3f34-f3ab-5ae6-768714b2e1a3@SystematicSw.ab.ca> Message-ID: <1e8676f6-5d3a-461c-21f5-f43bb60f166d@cs.ucla.edu> On 5/21/20 9:18 AM, Brian Inglis wrote: > System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); > [2019c] Thanks for that jshell recipe. I observe the same "2019c" on my Ubuntu 18.04.4 laptop, even though Ubuntu 18.04.4 has updated tzdata to 2020a, as can be seen from this shell command: $ zdump -V -c 2020,2021 America/Dawson America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 MST isdst=0 gmtoff=-25200 So I am observing the same symptoms that Sundar Sarma reports: my tzdata package is up-to-date but its Java copy is not. There are recipes for fixing the problem by updating the Java copy. For Oracle Java, see . For OpenJDK or some other Java, you can try ZIUpdater , tzdbgen , and/or IANA Updater . I'm not going to bother to run any of those since I don't normally run Java apps on my laptop. This Java stuff is all downstream from the tz project proper, so those who have problems with it should contact whoever's maintaining the Java software they're using. From Brian.Inglis at SystematicSw.ab.ca Thu May 21 21:42:00 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Thu, 21 May 2020 15:42:00 -0600 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <1e8676f6-5d3a-461c-21f5-f43bb60f166d@cs.ucla.edu> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <6764db79-3f34-f3ab-5ae6-768714b2e1a3@SystematicSw.ab.ca> <1e8676f6-5d3a-461c-21f5-f43bb60f166d@cs.ucla.edu> Message-ID: On 2020-05-21 14:33, Paul Eggert wrote: > On 5/21/20 9:18 AM, Brian Inglis wrote: > >> System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); >> [2019c] > > Thanks for that jshell recipe. I observe the same "2019c" on my Ubuntu 18.04.4 > laptop, even though Ubuntu 18.04.4 has updated tzdata to 2020a, as can be seen > from this shell command: > > $ zdump -V -c 2020,2021 America/Dawson > America/Dawson? Sun Mar? 8 09:59:59 2020 UT = Sun Mar? 8 01:59:59 2020 PST > isdst=0 gmtoff=-28800 > America/Dawson? Sun Mar? 8 10:00:00 2020 UT = Sun Mar? 8 03:00:00 2020 MST > isdst=0 gmtoff=-25200 > > So I am observing the same symptoms that Sundar Sarma reports: my tzdata package > is up-to-date but its Java copy is not. > > There are recipes for fixing the problem by updating the Java copy. > For Oracle Java, see > . > For OpenJDK or some other Java, you can try ZIUpdater > , > tzdbgen , > and/or IANA Updater . > I'm not going to bother to run any of those since I don't normally run Java > apps on my laptop. > > This Java stuff is all downstream from the tz project proper, so those who have > problems with it should contact whoever's maintaining the Java software they're > using. There should be coordination within each distro about triggering the local Java package TZ updater when the system tzdata is updated. My weekly cron tzdata release check script would run the TZ Updater against the new release if I still had Java and its TZ Updater installed: it's not hard. Perhaps those with wide deployments of distros with Java packages and apps could submit bug reports against their distro Java packages to apply TZ updates when tzdata packages are updated. Perhaps vendor JVM providers could sponsor packaging their JVM, TZ Updaters, and applying TZ updates when system tzdata is updated on distros they support using, rather than leaving it to system or app support or users. I haven't searched, but apparently even MS Windows now includes tzdata to support their MS Windows store apps or its infrastructure, and must update that, along with their proprietary Windows TZ updates. JVM providers could help more to keep their tzdata up to date, and that could and should be seen as a competitive advantage. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From john.haxby at oracle.com Fri May 22 09:50:11 2020 From: john.haxby at oracle.com (John Haxby) Date: Fri, 22 May 2020 10:50:11 +0100 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: > On 20 May 2020, at 23:03, Paul Eggert wrote: > > Tim Parenti's recent emails to the list reminded me that I'd long been meaning to nominate him to be my backup as TZ Coordinator. We should have a backup in case I am no longer available due to retirement or whatever, not that I'm planning to retire any time soon. I would like to start by giving him commit privileges to the development repository on GitHub, so that his contributions can become part of releases more easily. > > Tim has been a longtime and substantial contributor to tzdb, as evidenced by his detailed and careful patches. Although he's mostly worked in the tzdata area, he's also proficient on the code side, as his recent patch proposals demonstrate. He and I have corresponded by email about this and he's indicated his willingness to take on the responsibility. I'd appreciate reactions to Tim's offer to be backup; please respond within the next week. +1 jch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: Message signed with OpenPGP URL: From michael.h.deckers at googlemail.com Fri May 22 12:01:13 2020 From: michael.h.deckers at googlemail.com (Michael H Deckers) Date: Fri, 22 May 2020 12:01:13 +0000 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <475f9d7b-4dc7-0e5a-eaed-9bd372b3ecbf@googlemail.com> ? On 2020-05-20 22:03, Paul Eggert wrote: > ?I'd appreciate reactions to Tim's offer to be backup; please respond > within the next week. ? +1 ? Michael Deckers. From gkssarma59 at gmail.com Fri May 22 16:10:29 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Fri, 22 May 2020 21:40:29 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: we have used this code to get the IANA tz version. public static String getTimezoneDatabaseIANAVersion() { File readmeFile = new File(ZONEINFO_PATH, "README"); File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); if (!readmeFile.exists()) { readmeFile = alternativeReadmeFile; } out read me.txt file contain generated by Gradle Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz means we are using correct tzdata2020a. But still why there is issue? Something wrong with tz db?? regards, sundar On Fri, May 22, 2020 at 9:12 PM Sundar Sarma wrote: > ZoneRulesProvider.getVersions( String zoneId ). > which gives the version used by Java. > > this above code gives the version used by java. > > that is correct. Bu the above code is java.time > > we are using joda.time in our application. > > So could you please tell me that how to get the version used by java in > joda time?? > > thanks, > sundar > > On Thu, May 21, 2020 at 6:39 PM Michael H Deckers < > michael.h.deckers at googlemail.com> wrote: > >> >> On 2020-05-21 12:39, Sundar Sarma wrote: >> >> >> > Still i did not understand why this test case is failing with new 2020a >> tz. >> >> >> The version of the IANA database installed in the operating >> system may well differ from the version used by Java.time. >> The latter can be determined with the method >> ZoneRulesProvider.getVersions?( String zoneId ). >> which gives the version used by Java. >> >> HTH. >> >> Michael Deckers. >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Fri May 22 17:46:16 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Fri, 22 May 2020 11:46:16 -0600 Subject: [tz] Java Installed TZ DB Release Reporting (was: Welcome to the "tz" mailing list) In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> On 2020-05-22 10:10, Sundar Sarma wrote: > we have used this code to get the IANA tz version. > > public static String getTimezoneDatabaseIANAVersion() { > > ? ? ? ? File readmeFile = new File(ZONEINFO_PATH, "README"); > ? ? ? ? File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); > > ? ? ? ? if (!readmeFile.exists()) { > ? ? ? ? ? ? readmeFile = alternativeReadmeFile; > ? ? ? ? } > > out read me.txt file contain > > generated by Gradle > Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz > > means we are using correct tzdata2020a. > > But still why there is issue? Something wrong with tz db?? Just because there is a file present on your system does not mean that the TZ DB data has been successfully or correctly installed in the JVM you are running, unless that data is known to be directly used by your JVM as TZ data. Please consider using the suggested Java statement or command that directly queries your JVM: System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); *OR* $ jshell <<< 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' *OR* $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat *OR* equivalent if you are running other JVMs; you also need to follow up with your Java, JVM, workstation or server support staff to get TZ DB updates successfully and correctly downloaded and installed in the JVMs you and others are running on a regular basis. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From gkssarma59 at gmail.com Fri May 22 20:43:44 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Sat, 23 May 2020 02:13:44 +0530 Subject: [tz] Java Installed TZ DB Release Reporting (was: Welcome to the "tz" mailing list) In-Reply-To: <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> Message-ID: Instead of java.time (System.out.println(java.time.z one.ZoneRulesProvider.getVersions("UTC").keySet());)) ) I want the above code in joda.time. Could you please help me?? I didn't get ZoneRulesProvider.getVersions in joda.time.. On Fri, 22 May 2020, 23:16 Brian Inglis, wrote: > On 2020-05-22 10:10, Sundar Sarma wrote: > > we have used this code to get the IANA tz version. > > > > public static String getTimezoneDatabaseIANAVersion() { > > > > File readmeFile = new File(ZONEINFO_PATH, "README"); > > File alternativeReadmeFile = new File(ZONEINFO_PATH, > "README.txt"); > > > > if (!readmeFile.exists()) { > > readmeFile = alternativeReadmeFile; > > } > > > > out read me.txt file contain > > > > generated by Gradle > > Based on > http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz > > > > means we are using correct tzdata2020a. > > > > But still why there is issue? Something wrong with tz db?? > > Just because there is a file present on your system does not mean that the > TZ DB > data has been successfully or correctly installed in the JVM you are > running, > unless that data is known to be directly used by your JVM as TZ data. > > Please consider using the suggested Java statement or command that directly > queries your JVM: > > > System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); > > *OR* > > $ jshell <<< > > 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' > > *OR* > > $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' > /usr/lib/jvm/*/lib/tzdb.dat > > *OR* > > equivalent if you are running other JVMs; > you also need to follow up with your Java, JVM, workstation or server > support > staff to get TZ DB updates successfully and correctly downloaded and > installed > in the JVMs you and others are running on a regular basis. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Fri May 22 21:15:40 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Fri, 22 May 2020 15:15:40 -0600 Subject: [tz] Joda-time Installed TZ DB Release Reporting and Updating (was: Java Installed TZ DB Release Reporting) In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> Message-ID: You can easily find out the proper places to ask these questions with a simple search for the project Joda-time! It is not on this list which does not support downstream products and derivatives, many of which should not be used in any production system, as they do nothing towards the essential task of updating the data, or providing clear and usable automated processes or documentation about maintaining the data, or providing processes or information about managing it. To find out if it is possible to query the time zone version under Joda time, raise a documentation issue at: https://github.com/JodaOrg/joda-time/issues and request they provide the sample code and add that to their documentation. To update Joda-time TZ data follow the build process at to rebuild the library: https://www.joda.org/joda-time/tz_update.html and raise an operational issue requesting an automated process be added to automatically download, apply, and update the library. As recommended you should have upgraded from this project to java.time when Java 8 was released: https://www.joda.org/joda-time/index.html -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] On 2020-05-22 14:43, Sundar Sarma wrote: > Instead of java.time > (System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());)) > ) > > I want the above code in joda.time. Could you please help me??? > I didn't get ZoneRulesProvider.getVersions in joda.time..? > > > On Fri, 22 May 2020, 23:16 Brian Inglis, > wrote: > > On 2020-05-22 10:10, Sundar Sarma wrote: > > we have used this code to get the IANA tz version. > > > > public static String getTimezoneDatabaseIANAVersion() { > > > > ? ? ? ? File readmeFile = new File(ZONEINFO_PATH, "README"); > > ? ? ? ? File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); > > > > ? ? ? ? if (!readmeFile.exists()) { > > ? ? ? ? ? ? readmeFile = alternativeReadmeFile; > > ? ? ? ? } > > > > out read me.txt file contain > > > > generated by Gradle > > Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz > > > > means we are using correct tzdata2020a. > > > > But still why there is issue? Something wrong with tz db?? > > Just because there is a file present on your system does not mean that the TZ DB > data has been successfully or correctly installed in the JVM you are running, > unless that data is known to be directly used by your JVM as TZ data. > > Please consider using the suggested Java statement or command that directly > queries your JVM: > > System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); > > *OR* > > $ jshell <<< > 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' > > *OR* > > $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat > > *OR* > > equivalent if you are running other JVMs; > you also need to follow up with your Java, JVM, workstation or server support > staff to get TZ DB updates successfully and correctly downloaded and installed > in the JVMs you and others are running on a regular basis. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] From michael.h.deckers at googlemail.com Sat May 23 13:17:35 2020 From: michael.h.deckers at googlemail.com (Michael H Deckers) Date: Sat, 23 May 2020 13:17:35 +0000 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: <479d05d0-c3ed-cca2-6db1-b7fdbc2f03e4@googlemail.com> ?? On 2020-05-22 15:42, Sundar Sarma wrote: > So could you please tell me that how to get the version used by java in > joda time?? ?? Joda time uses their own time zone data. I do not ?? think you can ask for the version (but I have not looked ?? into Joda time in ages). You can, however, list the data ?? that Joda time keeps for a time zone by repeatedly calling ?? the method? DateTimeZone.nextTransition(instant). ?? HTH ?? Michael Deckers. From listclient at hayo.de Sun May 24 11:38:57 2020 From: listclient at hayo.de (listclient at hayo.de) Date: Sun, 24 May 2020 13:38:57 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] Message-ID: Hi all, when checking the timezone database version on my OpenSuse 15.1 Linux, I do not get the expected result. hayo at computer:~> sudo zdump --version zdump (tzcode) unknown Installed package: timezone - Time Zone Descriptions Is this a defect of the OpenSuse package or of the IANA code distribution? Regards, Hayo More Details ------------ Technical data: Installierte Version 2020a-lp151.2.9.1 Mo 18 Mai 2020 10:13:45 CEST Sa 23 Mai 2020 20:03:30 CEST System/Base BSD-3-Clause AND SUSE-Public-Domain 1,1 MiB 0 B openSUSE Leap 15.1 openSUSE http://bugs.opensuse.org x86_64 http://www.iana.org/time-zones timezone-2020a-lp151.2.9.1 0 File list: /etc/localtime /usr/bin/tzselect /usr/sbin/zdump /usr/sbin/zic /usr/share/zoneinfo ... Change log: Fr 24 Apr 2020 14:00:00 CEST Marketa Calabkova - timezone update 2020a (bsc#1169582) * Morocco springs forward on 2020-05-31, not 2020-05-24. * Canada's Yukon advanced to -07 year-round on 2020-03-08. * America/Nuuk renamed from America/Godthab. * zic now supports expiration dates for leap second lists. From eggert at cs.ucla.edu Sun May 24 17:19:58 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 24 May 2020 10:19:58 -0700 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: On 5/24/20 4:38 AM, listclient at hayo.de wrote: > sudo zdump --version > zdump (tzcode) unknown > > Installed package: > timezone - Time Zone Descriptions > > Is this a defect of the OpenSuse package or of the IANA code distribution? If you aren't sure, then the answer is "OpenSuse". :-) I suggest filing a bug report with the OpenSuse folks. For what it's worth, on Ubuntu 18.04.4 'zdump --version' outputs "zdump (Ubuntu GLIBC 2.27-3ubuntu1) 2.27" and on Fedora 31 it outputs "zdump (GNU libc) 2.30". From N.Semlali at iam.ma Sun May 24 07:51:25 2020 From: N.Semlali at iam.ma (Semlali Naoufal) Date: Sun, 24 May 2020 07:51:25 +0000 Subject: [tz] Fwd: TR: Morocco : Time Change Message-ID: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Hello, I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. Has the patch below been deployed correctly? For iPhone, the time is not changed. Regards, -----Message d'origine----- De : Paul Eggert Envoy? : mercredi 15 avril 2020 06:26 ? : Semlali Naoufal ; Tim Parenti Cc : Maamar Abdelkader ; Time zone mailing list Objet : Re: Morocco : Time Change Thanks for the heads-up. A proposed patch is attached. Looks like we'll need a new tzdb release soon, since the current release is wrong for Morocco starting May 24. ________________________________ [Description : cid:image002.jpg at 01CC9EE4.44A57D10]Eco ? geste: privil?giez la sauvegarde ?lectronique, si n?cessaire imprimez en recto-verso ________________________________ Ce message et toutes les pi?ces jointes sont adress?s ? l'attention exclusive de leurs destinataires et sont strictement confidentiels. Si vous le recevez par erreur, merci de le d?truire apr?s en avoir inform? l'exp?diteur sans d?lai. Toute divulgation, copie ou usage par une personne autre que son destinataire sont interdits. Maroc Telecom d?cline toute responsabilit? pour toute alt?ration, d?formation ou falsification subie par le message au cours de sa transmission. Retrouvez toutes les informations de Maroc Telecom sur www.iam.ma . ________________________________ This message and its attachments are intended only for the person or entity to which it is addressed and are strictly confidential. If you have received this in error, please delete the material from any computer after having informed the sender. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited. Maroc Telecom accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about Maroc Telecom on www.iam.ma . From eggert at cs.ucla.edu Sun May 24 18:45:19 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 24 May 2020 11:45:19 -0700 Subject: [tz] Morocco time change not working on many Android phones In-Reply-To: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> References: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Message-ID: On 5/24/20 12:51 AM, Semlali Naoufal wrote: > I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. > > Has the patch below been deployed correctly? Yes and no. It depends on your Android phone's support and whether you've updated its software recently and rebooted. Android has a complex relationship with tzdata. According to , time zone data is distributed in Android 10 via an Android Pony Express (APEX) container and in Android 8.1 and 9 via an Android Package (APK), and updates take effect after you reboot your phone. I guess in earlier releases tzdata was just part of the operating system. (If Android is like GNU/Linux it has two copies of tzdata, one for Java and the other for native apps; if so, I suppose it's possible for the two copies to disagree.) So, whether your Android phone works in Morocco right now depends on how well your phone's supplier updated its APEX or APX or OS (depending on how old the phone is) and whether you've rebooted. I just now checked the Android clock application in two recently-rebooted Android phones in my household, and one (a Nokia 6.1 running Android 10 - April security patch) had the wrong time for Morocco, whereas the other (an Essential PH-1 running Android 10 - February security patch) had the correct time. Nokia is pretty good about keeping the Nokia 6.1 up to date, but apparently has not issued an APEX container for tzdb 2020a (or maybe has mistakenly issued both APEX and APX with an out-of-date APX). Essential went out of business in February so it surprised me that its phone's tzdata is up to date; perhaps the APEX updating mechanism is not vendor-specific? I searched online for how this APEX stuff really works and came up empty. I don't know how Google broadcasts the latest APEX version for tzdata, or why the Essential PH-1's tzdata is up-to-date despite not having OS updates since February. Perhaps someone with some Android expertise could chime in. There are two bottom lines here. 1. Your experience will vary depending on who is maintaining your Android phone. 2. The Moroccan government should announce its time zone rules much earlier if it wants more of its people's phones to work correctly. From scolebourne at joda.org Mon May 25 07:28:09 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 25 May 2020 08:28:09 +0100 Subject: [tz] Joda-time Installed TZ DB Release Reporting and Updating (was: Java Installed TZ DB Release Reporting) In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> Message-ID: The list of time-zone database versions can be seen in the release notes: https://www.joda.org/joda-time/changes-report.html Stephen On Fri, 22 May 2020 at 22:16, Brian Inglis wrote: > > You can easily find out the proper places to ask these questions with a simple > search for the project Joda-time! > > It is not on this list which does not support downstream products and > derivatives, many of which should not be used in any production system, as they > do nothing towards the essential task of updating the data, or providing clear > and usable automated processes or documentation about maintaining the data, or > providing processes or information about managing it. > > To find out if it is possible to query the time zone version under Joda time, > raise a documentation issue at: > > https://github.com/JodaOrg/joda-time/issues > > and request they provide the sample code and add that to their documentation. > > To update Joda-time TZ data follow the build process at to rebuild the library: > > https://www.joda.org/joda-time/tz_update.html > > and raise an operational issue requesting an automated process be added to > automatically download, apply, and update the library. > > As recommended you should have upgraded from this project to java.time when Java > 8 was released: > > https://www.joda.org/joda-time/index.html > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > > > On 2020-05-22 14:43, Sundar Sarma wrote: > > Instead of java.time > > (System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());)) > > ) > > > > I want the above code in joda.time. Could you please help me?? > > I didn't get ZoneRulesProvider.getVersions in joda.time.. > > > > > > On Fri, 22 May 2020, 23:16 Brian Inglis, > > wrote: > > > > On 2020-05-22 10:10, Sundar Sarma wrote: > > > we have used this code to get the IANA tz version. > > > > > > public static String getTimezoneDatabaseIANAVersion() { > > > > > > File readmeFile = new File(ZONEINFO_PATH, "README"); > > > File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); > > > > > > if (!readmeFile.exists()) { > > > readmeFile = alternativeReadmeFile; > > > } > > > > > > out read me.txt file contain > > > > > > generated by Gradle > > > Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz > > > > > > means we are using correct tzdata2020a. > > > > > > But still why there is issue? Something wrong with tz db?? > > > > Just because there is a file present on your system does not mean that the TZ DB > > data has been successfully or correctly installed in the JVM you are running, > > unless that data is known to be directly used by your JVM as TZ data. > > > > Please consider using the suggested Java statement or command that directly > > queries your JVM: > > > > System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); > > > > *OR* > > > > $ jshell <<< > > 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' > > > > *OR* > > > > $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat > > > > *OR* > > > > equivalent if you are running other JVMs; > > you also need to follow up with your Java, JVM, workstation or server support > > staff to get TZ DB updates successfully and correctly downloaded and installed > > in the JVMs you and others are running on a regular basis. > > > > -- > > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > > > This email may be disturbing to some readers as it contains > > too much technical detail. Reader discretion is advised. > > [Data in IEC units and prefixes, physical quantities in SI.] From listclient at hayo.de Mon May 25 09:20:09 2020 From: listclient at hayo.de (listclient at hayo.de) Date: Mon, 25 May 2020 11:20:09 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: Am 24.05.20 um 19:19 schrieb Paul Eggert: > On 5/24/20 4:38 AM, listclient at hayo.de wrote: >> sudo zdump --version >> zdump (tzcode) unknown >> >> Installed package: >> timezone - Time Zone Descriptions >> >> Is this a defect of the OpenSuse package or of the IANA code distribution? > > If you aren't sure, then the answer is "OpenSuse". :-) > > I suggest filing a bug report with the OpenSuse folks. opensuse.org and new suse.com both are currently migrating user accounts. In short: I cannot log in to the Suse-Bugzilla. That is why the maintainer from Suse was and is addressed by this thread. M. Calabkova, please take care of this bug. >For what it's worth, on Ubuntu 18.04.4 'zdump --version' outputs >"zdump (Ubuntu GLIBC 2.27-3ubuntu1) 2.27" and on Fedora 31 it outputs >"zdump (GNU libc) 2.30". I expected this result. Thanks for your support. Regards, Hayo From mcalabkova at suse.cz Mon May 25 09:22:05 2020 From: mcalabkova at suse.cz (mcalabkova) Date: Mon, 25 May 2020 11:22:05 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: On 2020-05-24 19:19, Paul Eggert wrote: > On 5/24/20 4:38 AM, listclient at hayo.de wrote: >> sudo zdump --version >> zdump (tzcode) unknown >> >> Installed package: >> timezone - Time Zone Descriptions >> >> Is this a defect of the OpenSuse package or of the IANA code >> distribution? > > If you aren't sure, then the answer is "OpenSuse". :-) indeed :) I found out we were re-making a 'version' file (because of patches) > > I suggest filing a bug report with the OpenSuse folks. For what it's > worth, on > Ubuntu 18.04.4 'zdump --version' outputs "zdump (Ubuntu GLIBC > 2.27-3ubuntu1) > 2.27" and on Fedora 31 it outputs "zdump (GNU libc) 2.30". after fixing the issue above on my computer I get: $ sudo zdump --version zdump (tzcode) 2020a This is different from other distros. Is there any other bug in openSUSE? It looks like the other distros take version info from the last used compiler... Is this correct? Greetings, Marketa From philip at trouble.is Mon May 25 09:31:27 2020 From: philip at trouble.is (Philip Paeps) Date: Mon, 25 May 2020 17:31:27 +0800 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: <56C8137B-FD4F-4F58-B5AF-E7A0AB4FC549@trouble.is> On 2020-05-25 17:22:05 (+0800), mcalabkova wrote: > On 2020-05-24 19:19, Paul Eggert wrote: >> On 5/24/20 4:38 AM, listclient at hayo.de wrote: >>> sudo zdump --version >>> zdump (tzcode) unknown >>> >>> Installed package: >>> timezone - Time Zone Descriptions >>> >>> Is this a defect of the OpenSuse package or of the IANA code >>> distribution? >> >> If you aren't sure, then the answer is "OpenSuse". :-) > > indeed :) I found out we were re-making a 'version' file (because of > patches) > >> >> I suggest filing a bug report with the OpenSuse folks. For what it's >> worth, on >> Ubuntu 18.04.4 'zdump --version' outputs "zdump (Ubuntu GLIBC >> 2.27-3ubuntu1) >> 2.27" and on Fedora 31 it outputs "zdump (GNU libc) 2.30". > > after fixing the issue above on my computer I get: > > $ sudo zdump --version > zdump (tzcode) 2020a > > This is different from other distros. Is there any other bug in > openSUSE? It > looks like the other distros take version info from the last used > compiler... > Is this correct? On FreeBSD and macOS, `zdump --version` returns the version of the zdump program, respectively: zdump: @(#)zdump.c 8.10 (FreeBSD) zdump: @(#)zdump.c 7.31 (macOS) Arguably, your update to OpenSUSE is more useful! Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises -------------- next part -------------- An HTML attachment was scrubbed... URL: From schwab at linux-m68k.org Mon May 25 09:50:31 2020 From: schwab at linux-m68k.org (Andreas Schwab) Date: Mon, 25 May 2020 11:50:31 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: (mcalabkova@suse.cz's message of "Mon, 25 May 2020 11:22:05 +0200") References: Message-ID: <871rn8ny1k.fsf@igel.home> On Mai 25 2020, mcalabkova wrote: > after fixing the issue above on my computer I get: > > $ sudo zdump --version > zdump (tzcode) 2020a > > This is different from other distros. Is there any other bug in openSUSE? > It > looks like the other distros take version info from the last used > compiler... You could set PACKAGE from %distribution, similar to what binutils and gdb do. Also, it would be good to set BUGEMAIL. Andreas. -- Andreas Schwab, schwab at linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From kre at munnari.OZ.AU Mon May 25 10:35:24 2020 From: kre at munnari.OZ.AU (Robert Elz) Date: Mon, 25 May 2020 17:35:24 +0700 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: <56C8137B-FD4F-4F58-B5AF-E7A0AB4FC549@trouble.is> References: <56C8137B-FD4F-4F58-B5AF-E7A0AB4FC549@trouble.is> Message-ID: <14589.1590402924@jinx.noi.kre.to> Date: Mon, 25 May 2020 17:31:27 +0800 From: "Philip Paeps" Message-ID: <56C8137B-FD4F-4F58-B5AF-E7A0AB4FC549 at trouble.is> | On FreeBSD and macOS, `zdump --version` returns [...] On NetBSD (-current) netbsd# zdump --version zdump (tzcode) 2019b (we don't update tzcode all that frequently, tzdata on the other hand is 2020a) kre From mcalabkova at suse.cz Mon May 25 12:20:15 2020 From: mcalabkova at suse.cz (mcalabkova) Date: Mon, 25 May 2020 14:20:15 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: <871rn8ny1k.fsf@igel.home> References: <871rn8ny1k.fsf@igel.home> Message-ID: <58d32da5f41e02e2e2050d80d713c612@suse.cz> On 2020-05-25 11:50, Andreas Schwab wrote: > On Mai 25 2020, mcalabkova wrote: > >> after fixing the issue above on my computer I get: >> >> $ sudo zdump --version >> zdump (tzcode) 2020a >> >> This is different from other distros. Is there any other bug in >> openSUSE? >> It >> looks like the other distros take version info from the last used >> compiler... > > You could set PACKAGE from %distribution, similar to what binutils and > gdb do. Also, it would be good to set BUGEMAIL. I have tried it (I have also set it to print a real package name) and I got: $ sudo zdump --version zdump (timezone; Base:System) 2020a (Base:System is the repository in which I locally build the package.) I personally dislike it, after reading the discussion I would stay with simple tzcode (the previous result). I will set BUGEMAIL to opensuse-support at opensuse.org, thanks. Hayo, are you satisfied with this solution? Greetings, Marketa From Brian.Inglis at SystematicSw.ab.ca Mon May 25 13:14:19 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Mon, 25 May 2020 07:14:19 -0600 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: <93de2c3d-67ef-a2c9-1e81-a64515eac83b@SystematicSw.ab.ca> On 2020-05-25 03:22, mcalabkova wrote: > On 2020-05-24 19:19, Paul Eggert wrote: >> On 5/24/20 4:38 AM, listclient at hayo.de wrote: >>> sudo zdump --version >>> zdump (tzcode) unknown >>> >>> Installed package: >>> timezone - Time Zone Descriptions >>> >>> Is this a defect of the OpenSuse package or of the IANA code distribution? >> >> If you aren't sure, then the answer is "OpenSuse". :-) > > indeed :) I found out we were re-making a 'version' file (because of patches) > >> >> I suggest filing a bug report with the OpenSuse folks. For what it's worth, on >> Ubuntu 18.04.4 'zdump --version' outputs "zdump (Ubuntu GLIBC 2.27-3ubuntu1) >> 2.27" and on Fedora 31 it outputs "zdump (GNU libc) 2.30". > > after fixing the issue above on my computer I get: > > $ sudo zdump --version > zdump (tzcode) 2020a > > This is different from other distros. Is there any other bug in openSUSE? It > looks like the other distros take version info from the last used compiler... > Is this correct? A number of distros do not use tzcode directly, but have their own release, based on their libc TZ and locale handling, applying patches based on tzcode patches, or based on BSD to allow use and inclusion in commercial or proprietary products, often RT or embedded systems for microcontrollers, with tailored support for data, functionality, size. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From Brian.Inglis at SystematicSw.ab.ca Mon May 25 13:14:26 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Mon, 25 May 2020 07:14:26 -0600 Subject: [tz] Morocco time change not working on many Android phones In-Reply-To: References: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Message-ID: <7eae207d-6197-4c33-5828-f60bbb2b8214@SystematicSw.ab.ca> On 2020-05-24 12:45, Paul Eggert wrote: > On 5/24/20 12:51 AM, Semlali Naoufal wrote: >> I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. >> >> Has the patch below been deployed correctly? > > Yes and no. It depends on your Android phone's support and whether you've > updated its software recently and rebooted. > > Android has a complex relationship with tzdata. According to > , time zone data > is distributed in Android 10 via an Android Pony Express (APEX) container and in > Android 8.1 and 9 via an Android Package (APK), and updates take effect after > you reboot your phone. I guess in earlier releases tzdata was just part of the > operating system. (If Android is like GNU/Linux it has two copies of tzdata, one > for Java and the other for native apps; if so, I suppose it's possible for the > two copies to disagree.) > > So, whether your Android phone works in Morocco right now depends on how well > your phone's supplier updated its APEX or APX or OS (depending on how old the > phone is) and whether you've rebooted. I just now checked the Android clock > application in two recently-rebooted Android phones in my household, and one (a > Nokia 6.1 running Android 10 - April security patch) had the wrong time for > Morocco, whereas the other (an Essential PH-1 running Android 10 - February > security patch) had the correct time. > > Nokia is pretty good about keeping the Nokia 6.1 up to date, but apparently has > not issued an APEX container for tzdb 2020a (or maybe has mistakenly issued both > APEX and APX with an out-of-date APX). Essential went out of business in > February so it surprised me that its phone's tzdata is up to date; perhaps the > APEX updating mechanism is not vendor-specific? > > I searched online for how this APEX stuff really works and came up empty. I > don't know how Google broadcasts the latest APEX version for tzdata, or why the > Essential PH-1's tzdata is up-to-date despite not having OS updates since > February. Perhaps someone with some Android expertise could chime in. > > There are two bottom lines here. > > 1. Your experience will vary depending on who is maintaining your Android phone. > > 2. The Moroccan government should announce its time zone rules much earlier if > it wants more of its people's phones to work correctly. In many cases, it is up to the phone hardware vendor e.g. Samsung or network vendor e.g. telco, who customize Android for their hardware platform or their network infrastructure, to customize and forward security and system updates. Apple is good about this for iOS and many old phones still get updates, until they are so old that certain updates may not be applied to them. Google is trying to promote and bypass vendors for security and system updates, as Android systems have a poor rep for security and updates: maybe 1.5-3 years support from release of a model from a vendor, and limited support from telcos, concentrating on recently sold sets. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From listclient at hayo.de Mon May 25 12:49:29 2020 From: listclient at hayo.de (listclient at hayo.de) Date: Mon, 25 May 2020 14:49:29 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: <58d32da5f41e02e2e2050d80d713c612@suse.cz> References: <871rn8ny1k.fsf@igel.home> <58d32da5f41e02e2e2050d80d713c612@suse.cz> Message-ID: <2dec48f7-2b64-ded2-9a99-0c8c64b7a1e3@hayo.de> Am 25.05.20 um 14:20 schrieb mcalabkova: > On 2020-05-25 11:50, Andreas Schwab wrote: >> On Mai 25 2020, mcalabkova wrote: >> >>> after fixing the issue above on my computer I get: >>> >>> $ sudo zdump --version >>> zdump (tzcode) 2020a >>> >>> This is different from other distros. Is there any other bug in >>> openSUSE? >>> It >>> looks like the other distros take version info from the last used >>> compiler... >> >> You could set PACKAGE from %distribution, similar to what binutils and >> gdb do.? Also, it would be good to set BUGEMAIL. > > I have tried it (I have also set it to print a real package name) and I > got: > > $ sudo zdump --version > zdump (timezone; Base:System) 2020a > > (Base:System is the repository in which I locally build the package.) > > I personally dislike it, after reading the discussion I would stay with > simple tzcode (the previous result). > > I will set BUGEMAIL to opensuse-support at opensuse.org, thanks. > > Hayo, are you satisfied with this solution? Marketa, from the perspective of the OpenSuse user I am fully satisfied with the solution. In fact I expected 'sudo zdump --version' to return the database version. But the man page is unspecific in its description. >From the perspective of the zdump user, the current situation is not that good. I think all distributions should return similar output. And the output should contain the tzdata version. Only that way it is possible to evaluate the output in portable scripts. Proposal (for a future version >2020a): $ sudo zdump --version zdump (GLIBC 2.28) - tzdata 2020c > > Greetings, > Marketa Greetings, Hayo From enh at google.com Tue May 26 15:37:09 2020 From: enh at google.com (enh) Date: Tue, 26 May 2020 08:37:09 -0700 Subject: [tz] Morocco time change not working on many Android phones In-Reply-To: References: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Message-ID: On Sun, May 24, 2020 at 11:45 AM Paul Eggert wrote: > > On 5/24/20 12:51 AM, Semlali Naoufal wrote: > > I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. > > > > Has the patch below been deployed correctly? > > Yes and no. It depends on your Android phone's support and whether you've > updated its software recently and rebooted. > > Android has a complex relationship with tzdata. According to > , time zone data > is distributed in Android 10 via an Android Pony Express (APEX) container and in > Android 8.1 and 9 via an Android Package (APK), and updates take effect after > you reboot your phone. I guess in earlier releases tzdata was just part of the > operating system. (If Android is like GNU/Linux it has two copies of tzdata, one > for Java and the other for native apps; if so, I suppose it's possible for the > two copies to disagree.) like Linux, no: ART doesn't have its own copy of tzdata. are there two copies? yes: icu has its own slightly different database built from tzdata, in addition the "normal" (it's just all the tzdata files concatenated with a small header) tzdata. but they're both in the apk or apex. > So, whether your Android phone works in Morocco right now depends on how well > your phone's supplier updated its APEX or APX or OS (depending on how old the > phone is) and whether you've rebooted. I just now checked the Android clock > application in two recently-rebooted Android phones in my household, and one (a > Nokia 6.1 running Android 10 - April security patch) had the wrong time for > Morocco, whereas the other (an Essential PH-1 running Android 10 - February > security patch) had the correct time. > > Nokia is pretty good about keeping the Nokia 6.1 up to date, but apparently has > not issued an APEX container for tzdb 2020a (or maybe has mistakenly issued both > APEX and APX with an out-of-date APX). Essential went out of business in > February so it surprised me that its phone's tzdata is up to date; perhaps the > APEX updating mechanism is not vendor-specific? > > I searched online for how this APEX stuff really works and came up empty. I > don't know how Google broadcasts the latest APEX version for tzdata, or why the > Essential PH-1's tzdata is up-to-date despite not having OS updates since > February. Perhaps someone with some Android expertise could chime in. apexes, like apks, are updated via the Play Store. > There are two bottom lines here. > > 1. Your experience will vary depending on who is maintaining your Android phone. > > 2. The Moroccan government should announce its time zone rules much earlier if > it wants more of its people's phones to work correctly. From nfuller at google.com Wed May 27 12:03:40 2020 From: nfuller at google.com (Neil Fuller) Date: Wed, 27 May 2020 13:03:40 +0100 Subject: [tz] Morocco time change not working on many Android phones In-Reply-To: References: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Message-ID: To expand on what enh@ said and provide some more context: One of my responsibilities on Android is the time zone data source-code updates. I can confirm it's complicated! The short answer is that the Morocco change didn't give maintainers a lot of time to react. The number of devices, manufacturers and users involved for Android alone is quite humbling! Literally billions of devices, millions of users, spread over thousands of different types of device. I am a software engineer, so I can provide some technical information around Android tzdb updates for future reference (see text below my name). Paul is correct: it is my understanding that the Essential PH-1 device is using the Google-managed APEX update mechanism. I hope the information below helps explain what the situation is. As more devices move to the APEX update mechanism we should continue to see improvements here. That said, I think four working weeks from tzdb release to device is always going to be difficult with so many parties and devices involved. Neil. -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902 ------------- The Android OS has two main copies of time zone data: one that is used by Android's libc (bionic) and its java.util.TimeZone class, and a copy associated with Android's embedded of International Components for Unicode libraries (ICU4C and ICU4J). ICU has additional information like translations for zone names and other time zone metadata that need to be updated. Both copies are updated when I produce source code updates, though manufacturers can create their own source code updates if they wish. We alert partners to source updates for recent releases (currently from 8.0/Oreo up to Android 10) and we make them available to all via the AOSP project. For example, https://android-review.googlesource.com/q/topic:%22tzdb2020a_pie-dev%22+(status:open%20OR%20status:merged) is the Android 9 backport of the tzdb 2020a update. For many devices (i.e. those before Android 10, the Q3 2019 release) the device update process is entirely handled by the manufacturer, either via a full "over the air" (OTA) system image update, via the APK mechanism linked by Paul, or a proprietary mechanism. All these mechanisms the manufacturer is responsible for. For Android 10 devices that support APEX updates, Google now manages the update via Google Play System Update (internal name Project Mainline ). For devices that don't, the information for earlier releases is currently still true. I know the Android Mainline folks handling building / signing / QA and partner coordination for the Google-managed APEX update have been working hard to get an APEX update out in time for the Morocco offset change. For any update there still needs to be a lot of coordination between Google and the manufacturer partners. Google rolls out updates like this very carefully. My understanding is that the update was available to 100% of Mainline updatable devices by Friday 22nd May. Yesterday morning (26th May) I checked my personal Android 10 device (which I know does have Google-managed APEX updates), and found that it had updated to 2020a, but it did take a manual reboot by me before that was the case. On Tue, 26 May 2020 at 16:37, enh via tz wrote: > On Sun, May 24, 2020 at 11:45 AM Paul Eggert wrote: > > > > On 5/24/20 12:51 AM, Semlali Naoufal wrote: > > > I would like to inform you that the time has been advanced by one hour > today on Android Smartphones while the time change should not be made until > 31.05.2020 as already reported. > > > > > > Has the patch below been deployed correctly? > > > > Yes and no. It depends on your Android phone's support and whether you've > > updated its software recently and rebooted. > > > > Android has a complex relationship with tzdata. According to > > , time > zone data > > is distributed in Android 10 via an Android Pony Express (APEX) > container and in > > Android 8.1 and 9 via an Android Package (APK), and updates take effect > after > > you reboot your phone. I guess in earlier releases tzdata was just part > of the > > operating system. (If Android is like GNU/Linux it has two copies of > tzdata, one > > for Java and the other for native apps; if so, I suppose it's possible > for the > > two copies to disagree.) > > like Linux, no: ART doesn't have its own copy of tzdata. > > are there two copies? yes: icu has its own slightly different database > built from tzdata, in addition the "normal" (it's just all the tzdata > files concatenated with a small header) tzdata. but they're both in > the apk or apex. > > > So, whether your Android phone works in Morocco right now depends on how > well > > your phone's supplier updated its APEX or APX or OS (depending on how > old the > > phone is) and whether you've rebooted. I just now checked the Android > clock > > application in two recently-rebooted Android phones in my household, and > one (a > > Nokia 6.1 running Android 10 - April security patch) had the wrong time > for > > Morocco, whereas the other (an Essential PH-1 running Android 10 - > February > > security patch) had the correct time. > > > > Nokia is pretty good about keeping the Nokia 6.1 up to date, but > apparently has > > not issued an APEX container for tzdb 2020a (or maybe has mistakenly > issued both > > APEX and APX with an out-of-date APX). Essential went out of business in > > February so it surprised me that its phone's tzdata is up to date; > perhaps the > > APEX updating mechanism is not vendor-specific? > > > > I searched online for how this APEX stuff really works and came up > empty. I > > don't know how Google broadcasts the latest APEX version for tzdata, or > why the > > Essential PH-1's tzdata is up-to-date despite not having OS updates since > > February. Perhaps someone with some Android expertise could chime in. > > apexes, like apks, are updated via the Play Store. > > > There are two bottom lines here. > > > > 1. Your experience will vary depending on who is maintaining your > Android phone. > > > > 2. The Moroccan government should announce its time zone rules much > earlier if > > it wants more of its people's phones to work correctly. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naela.sarras at iana.org Wed May 27 20:52:06 2020 From: naela.sarras at iana.org (Naela Sarras) Date: Wed, 27 May 2020 20:52:06 +0000 Subject: [tz] FW: [Ext] The TZ Coordination Message-ID: Dear Paul, Please see the note below from our colleagues in Morocco regarding the upcoming timezone change for Morocco. Best regards, Naela Naela Sarras Director, IANA Operations ICANN From: EL MAAYATI Afaf Date: Wednesday, May 27, 2020 at 12:01 PM To: Naela Sarras Cc: BENLEMLIH Hamida Subject: [Ext] The TZ Coordination Dear Naela, I hope this email finds you well, safe and healthy. Actually, I have a request concerning the configuration of the Time-Zone for Morocco. In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it?s mentionned that a program will be running to implement the transition dates: [cid:image001.jpg at 01D6342E.01C70B10] Currently we are implementing GMT and we will move to GMT+1 next Sunday, May 31. So, if possible, would you please help to get in touch with Mr. Paul Eggert, in order to have the procedure to notify IANA officially, from a governmental source, with the changes of TZ in Morocco. Thank you in advance for your feedback and for your habitual support. Best Regards, Afaf ________________________________ Ce message, son contenu et toutes les pi?ces jointes sont adress?s ? l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils rel?vent de la correspondance priv?e. Toute publication, utilisation ou diffusion, m?me partielle, par des personnes autres que les destinataires est interdite et doit ?tre autoris?e par l'Agence Nationale de R?glementation des T?l?communications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le d?truire apr?s en avoir inform? son exp?diteur sans d?lai. L?ANRT d?cline toute responsabilit? pour toute alt?ration, d?formation ou falsification subi par le message et ses pi?ces jointes au cours de leur transmission. Retrouvez toutes les informations de l?ANRT sur son site Web ? l?adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ ?? ??? ??????? ???????? ????????? ????? ????? ????? ?????? ???? ?????? ???? ????? ??? ???? ????????? ??? ????? ?????. ????? ???? ???? ??? ?? ??????? ?? ??? ??? ?????? ?????? ???? ??????? ?? ??? ????? ??? ?????? ????? ?? ?? ??? ??????? ???? ?? ??? ??????? ??????? ?????? ????????? (??????? ????????. ?? ???? ?? ??? ?????? ??? ??????? ?? ???? ?????? ???? ???? ????? ??? ??????? ???? ??? ????? ????? ?????? ???? ????. ??? ????? ??????? ??????? ?????? ????????? ?? ??????? ?? ?? ????? ?? ????? ?? ????? ?? ???? ?????? ??????? ?? ????????? ???? ????? ???????. ?????? ?? ?????????? ???? ??????? ??? ?????? ?????????? ??????? ??????? ?????? ????????? : http://www.anrt.ma. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 81051 bytes Desc: image001.jpg URL: From eggert at cs.ucla.edu Thu May 28 00:48:28 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Wed, 27 May 2020 17:48:28 -0700 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: References: Message-ID: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> >From Afaf El Maayati (2020-05-27): > In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it?s mentioned that a program will be running to implement the transition dates That commentary refers to a program that I ran on April 14; it predicted daylight-saving transitions for Morocco for the years 2021 through 2087, and I installed those predictions into tzdb 2020a. We don't know now whether those predictions are correct, since the government of Morocco hasn't published plans for 2021 and later and it might change its mind before next year. Even so, the tzdb tradition is to predict plausible transitions that are more likely to be correct than a prediction of no transitions at all. > we will move to GMT+1 next Sunday, May 31. Yes, that transition is in tzdb 2020a (the current tzdb release), so tzdb should not need any changes for it. Currently, devices based on out-of-date tzdb releases are off by an hour for Morocco; these devices should start being correct on May 31. Devices based on tzdb 2020a should be correct both now and after May 31. PS. Of the devices I have ready access to, many are out-of-date and are therefore showing incorrect time for Morocco because it takes more than a few weeks to propagate tzdb changes via manufacturers and suppliers to the billions of devices on the planet. My up-to-date devices are running: * Android 10 with APEX updates from Google Play Store * iOS 13.3.1 * macOS 10.14.6 * Ubuntu 18.04.3 From eggert at cs.ucla.edu Thu May 28 07:23:27 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 28 May 2020 00:23:27 -0700 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: <2dec48f7-2b64-ded2-9a99-0c8c64b7a1e3@hayo.de> References: <871rn8ny1k.fsf@igel.home> <58d32da5f41e02e2e2050d80d713c612@suse.cz> <2dec48f7-2b64-ded2-9a99-0c8c64b7a1e3@hayo.de> Message-ID: On 5/25/20 5:49 AM, listclient at hayo.de wrote: > From the perspective of the zdump user, the current situation is not > that good. I think all distributions should return similar output. And > the output should contain the tzdata version. That's not what the --version flag is for. --version is supposed to output the version number of the program, not of any data. This is the common meaning of "--version" across a wide variety of programs. Many distributions update tzcode (the source code for zdump) more rarely than tzdata, and it's helpful to keep the two version numbers distinct in that case. zdump is intended to be portable to any system that conforms to POSIX, and since there's no POSIX-portable way to find out the tzdata version, zdump doesn't do that. There might not be any tzdata at all, and zdump is still supposed to work. Though perhaps this zdump design goal should change at some point.... From clive at davros.org Thu May 28 07:34:09 2020 From: clive at davros.org (Clive D.W. Feather) Date: Thu, 28 May 2020 08:34:09 +0100 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> Message-ID: <20200528073409.GA72460@davros.org> Paul Eggert said: > We don't know now whether those predictions are correct, since the government of > Morocco hasn't published plans for 2021 and later and it might change its mind > before next year. Even so, the tzdb tradition is to predict plausible > transitions that are more likely to be correct than a prediction of no > transitions at all. Would this be a good opportunity to engage with the government of Morocco to encourage them to give more warning? -- Clive D.W. Feather | If you lie to the compiler, Email: clive at davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 From guy at alum.mit.edu Thu May 28 09:39:47 2020 From: guy at alum.mit.edu (Guy Harris) Date: Thu, 28 May 2020 02:39:47 -0700 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: <871rn8ny1k.fsf@igel.home> <58d32da5f41e02e2e2050d80d713c612@suse.cz> <2dec48f7-2b64-ded2-9a99-0c8c64b7a1e3@hayo.de> Message-ID: On May 28, 2020, at 12:23 AM, Paul Eggert wrote: > That's not what the --version flag is for. --version is supposed to output the > version number of the program, not of any data. This is the common meaning of > "--version" across a wide variety of programs. Yes. For example, the GNU coding standard says of --version: https://www.gnu.org/prep/standards/standards.html#g_t_002d_002dversion "The standard --version option should direct the program to print information about its name, version, origin and legal status, all on standard output, and then exit successfully." > zdump is intended to be portable to any system that conforms to POSIX, and since > there's no POSIX-portable way to find out the tzdata version, zdump doesn't do > that. There might not be any tzdata at all, and zdump is still supposed to work. > Though perhaps this zdump design goal should change at some point.... And if there *were* a POSIX-portable way to find out the tzdata version, zdump should, *if* there's tzdata from which to find the version using the POSIX-portable way in question, have a *different* flag, e.g. --tzdata-version, to tell it to report that version. From eggert at cs.ucla.edu Thu May 28 16:47:41 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 28 May 2020 09:47:41 -0700 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> Message-ID: <4970e290-8f69-a4e6-7158-c682146f038d@cs.ucla.edu> On 5/28/20 3:41 AM, EL MAAYATI Afaf wrote: > we need to know if there is a procedure to notify IANA (TZ Coordination) officially, from a governmental source, with the official dates of TZ changes in Morocco. The procedure is to send email to tz at iana.org with official citations, preferably with pointers to copies in English since the mailing list is in English. For best results, give one years' notice before the dates of change. For more details, please see: https://data.iana.org/time-zones/tz-link.html#changes From jlladonosa at gmail.com Wed May 27 08:02:14 2020 From: jlladonosa at gmail.com (josep lladonosa capell) Date: Wed, 27 May 2020 10:02:14 +0200 Subject: [tz] Typo in a 1900 date of europe tz file Message-ID: Hello, I was just reading the europe tz file and found a typo. The comment in the file gives the date 26/6/1900 but in fact it was July (7) not June (6). In the same text there is a reference to the official document of 26/7/1900. Attached you will find the patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: myfix.patch Type: text/x-patch Size: 526 bytes Desc: not available URL: From fw at deneb.enyo.de Sat May 30 14:00:24 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 30 May 2020 16:00:24 +0200 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <20200528073409.GA72460@davros.org> (Clive D. W. Feather's message of "Thu, 28 May 2020 08:34:09 +0100") References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> Message-ID: <87y2p98qvb.fsf@mid.deneb.enyo.de> * Clive D. W. Feather: > Paul Eggert said: >> We don't know now whether those predictions are correct, since the government of >> Morocco hasn't published plans for 2021 and later and it might change its mind >> before next year. Even so, the tzdb tradition is to predict plausible >> transitions that are more likely to be correct than a prediction of no >> transitions at all. > > Would this be a good opportunity to engage with the government of Morocco > to encourage them to give more warning? My understanding is that at present, they don't know themselves in advance. They would have to redefine the criteria to something based exclusively on astronomical calculations, probably giving up the alignment with Ramadan. I don't know if this would be feasible. From eggert at cs.ucla.edu Sat May 30 23:03:54 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sat, 30 May 2020 16:03:54 -0700 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <87y2p98qvb.fsf@mid.deneb.enyo.de> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> Message-ID: <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> On 5/30/20 7:00 AM, Florian Weimer wrote: >> Would this be a good opportunity to engage with the government of Morocco >> to encourage them to give more warning? > My understanding is that at present, they don't know themselves in > advance. Yes, I think you're right. > They would have to redefine the criteria to something based > exclusively on astronomical calculations That shouldn't be necessary, as they're using a conservative approximation; that is, it's OK if their approximation is a bit off because all they need to do is to bracket the actual Ramadan rather than predict its Gregorian dates exactly. If they had an algorithm they could publish it and we could use it. And it would be technically feasible for them to have an algorithm; see the Morocco-prediction code in the tzdb 'africa' file for an example algorithm. Admittedly there are obstacles to getting all this to work. That being said, I suspect that the obstacles here are administrative, not religious or technical. We needed a tzdb 2020a because in 2019c I had predicted a tighter bound around the actual Ramadan, whereas the Moroccan authorities evidently wanted a looser bound. That is, Ramadan ended May 23 in Morocco, and tzdb 2019c had predicted May 24 for the spring-forward transition whereas the Moroccan government decided on May 31. PS. In about three hours the discrepancy will become moot, as Morocco will do its end-of-Ramadan spring-forward and after that the 2019c clocks will agree with the 2020a clocks. From fw at deneb.enyo.de Sun May 31 11:09:03 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 31 May 2020 13:09:03 +0200 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> (Paul Eggert's message of "Sat, 30 May 2020 16:03:54 -0700") References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> Message-ID: <877dws744w.fsf@mid.deneb.enyo.de> * Paul Eggert: > On 5/30/20 7:00 AM, Florian Weimer wrote: >>> Would this be a good opportunity to engage with the government of Morocco >>> to encourage them to give more warning? >> My understanding is that at present, they don't know themselves in >> advance. > > Yes, I think you're right. > >> They would have to redefine the criteria to something based >> exclusively on astronomical calculations > > That shouldn't be necessary, as they're using a conservative > approximation; that is, it's OK if their approximation is a bit off > because all they need to do is to bracket the actual Ramadan rather > than predict its Gregorian dates exactly. If they had an algorithm > they could publish it and we could use it. And it would be > technically feasible for them to have an algorithm; see the > Morocco-prediction code in the tzdb 'africa' file for an example > algorithm. It looks like the algorithm predicted correctly the data of Eid al-Fitr as 24 May, but the derivation of the end date from that is suspicious. I think it would make more sense if the time change does not happen on Eid itself. A rule like this would ensure that Eid still uses the same time as Ramadan in every year, which is likely what people expect. From milamberspace at gmail.com Sun May 31 14:03:50 2020 From: milamberspace at gmail.com (Milamber) Date: Sun, 31 May 2020 15:03:50 +0100 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <877dws744w.fsf@mid.deneb.enyo.de> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> Message-ID: <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> On 5/31/20 12:09 PM, Florian Weimer wrote: > * Paul Eggert: > >> On 5/30/20 7:00 AM, Florian Weimer wrote: >>>> Would this be a good opportunity to engage with the government of Morocco >>>> to encourage them to give more warning? >>> My understanding is that at present, they don't know themselves in >>> advance. >> Yes, I think you're right. >> >>> They would have to redefine the criteria to something based >>> exclusively on astronomical calculations >> That shouldn't be necessary, as they're using a conservative >> approximation; that is, it's OK if their approximation is a bit off >> because all they need to do is to bracket the actual Ramadan rather >> than predict its Gregorian dates exactly. If they had an algorithm >> they could publish it and we could use it. And it would be >> technically feasible for them to have an algorithm; see the >> Morocco-prediction code in the tzdb 'africa' file for an example >> algorithm. > It looks like the algorithm predicted correctly the data of Eid > al-Fitr as 24 May, but the derivation of the end date from that is > suspicious. I think it would make more sense if the time change does > not happen on Eid itself. In Morocco (where I live), the end of Ramadan (arabic month) is follow by the Eid al-Fitr, and concretely it's 1 or 2 day off for the people (with traditional visiting of family, big lunches/diners, etc.). So for this year the astronomical calculations don't include the following 2 day off in the calc. This 2 days have fall in a Sunday/Monday, so it's not acceptable by people to have a time shift during these 2 day off. Perhaps, you can modify the (predict) rules for next years : if the end of Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a weekend), the next time shift will be the next weekend. > A rule like this would ensure that Eid > still uses the same time as Ramadan in every year, which is likely > what people expect. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mj1856 at hotmail.com Sun May 31 17:25:10 2020 From: mj1856 at hotmail.com (Matt Johnson-Pint) Date: Sun, 31 May 2020 17:25:10 +0000 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de>, <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> Message-ID: Forgive me if this is in any way ignorant, but why must the DST transitions align so precisely with Ramadan? Would it not be sufficient if the dates for the time change were predictable as long as the switch to GMT occurred sometime before the start of Ramadan and the switch back to GMT+1 occurred sometime after? Is there a political, social, or religious reason why they must be so exactly aligned? -Matt ________________________________ From: tz on behalf of Milamber Sent: Sunday, May 31, 2020 7:03:50 AM To: Florian Weimer ; Paul Eggert Cc: Time zone mailing list Subject: Re: [tz] FW: [Ext] The TZ Coordination On 5/31/20 12:09 PM, Florian Weimer wrote: * Paul Eggert: On 5/30/20 7:00 AM, Florian Weimer wrote: Would this be a good opportunity to engage with the government of Morocco to encourage them to give more warning? My understanding is that at present, they don't know themselves in advance. Yes, I think you're right. They would have to redefine the criteria to something based exclusively on astronomical calculations That shouldn't be necessary, as they're using a conservative approximation; that is, it's OK if their approximation is a bit off because all they need to do is to bracket the actual Ramadan rather than predict its Gregorian dates exactly. If they had an algorithm they could publish it and we could use it. And it would be technically feasible for them to have an algorithm; see the Morocco-prediction code in the tzdb 'africa' file for an example algorithm. It looks like the algorithm predicted correctly the data of Eid al-Fitr as 24 May, but the derivation of the end date from that is suspicious. I think it would make more sense if the time change does not happen on Eid itself. In Morocco (where I live), the end of Ramadan (arabic month) is follow by the Eid al-Fitr, and concretely it's 1 or 2 day off for the people (with traditional visiting of family, big lunches/diners, etc.). So for this year the astronomical calculations don't include the following 2 day off in the calc. This 2 days have fall in a Sunday/Monday, so it's not acceptable by people to have a time shift during these 2 day off. Perhaps, you can modify the (predict) rules for next years : if the end of Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a weekend), the next time shift will be the next weekend. A rule like this would ensure that Eid still uses the same time as Ramadan in every year, which is likely what people expect. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoidsoft at gmail.com Sun May 31 18:22:23 2020 From: zoidsoft at gmail.com (Zoid Soft) Date: Sun, 31 May 2020 14:22:23 -0400 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> Message-ID: <9552C1BF-C837-46D0-B80E-DA0EDFE556D7@gmail.com> Astrologers have been significant contributors to this list. > On May 31, 2020, at 1:25 PM, Matt Johnson-Pint wrote: > > Forgive me if this is in any way ignorant, but why must the DST transitions align so precisely with Ramadan? Would it not be sufficient if the dates for the time change were predictable as long as the switch to GMT occurred sometime before the start of Ramadan and the switch back to GMT+1 occurred sometime after? Is there a political, social, or religious reason why they must be so exactly aligned? > > -Matt > From: tz on behalf of Milamber > Sent: Sunday, May 31, 2020 7:03:50 AM > To: Florian Weimer ; Paul Eggert > Cc: Time zone mailing list > Subject: Re: [tz] FW: [Ext] The TZ Coordination > > > > On 5/31/20 12:09 PM, Florian Weimer wrote: >> * Paul Eggert: >> >>> On 5/30/20 7:00 AM, Florian Weimer wrote: >>>>> Would this be a good opportunity to engage with the government of Morocco >>>>> to encourage them to give more warning? >>>> My understanding is that at present, they don't know themselves in >>>> advance. >>> Yes, I think you're right. >>> >>>> They would have to redefine the criteria to something based >>>> exclusively on astronomical calculations >>> That shouldn't be necessary, as they're using a conservative >>> approximation; that is, it's OK if their approximation is a bit off >>> because all they need to do is to bracket the actual Ramadan rather >>> than predict its Gregorian dates exactly. If they had an algorithm >>> they could publish it and we could use it. And it would be >>> technically feasible for them to have an algorithm; see the >>> Morocco-prediction code in the tzdb 'africa' file for an example >>> algorithm. >> It looks like the algorithm predicted correctly the data of Eid >> al-Fitr as 24 May, but the derivation of the end date from that is >> suspicious. I think it would make more sense if the time change does >> not happen on Eid itself. > > > In Morocco (where I live), the end of Ramadan (arabic month) is follow by the Eid al-Fitr, and concretely it's 1 or 2 day off for the people (with traditional visiting of family, big lunches/diners, etc.). So for this year the astronomical calculations don't include the following 2 day off in the calc. This 2 days have fall in a Sunday/Monday, so it's not acceptable by people to have a time shift during these 2 day off. > > Perhaps, you can modify the (predict) rules for next years : if the end of Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a weekend), the next time shift will be the next weekend. > > > > >> A rule like this would ensure that Eid >> still uses the same time as Ramadan in every year, which is likely >> what people expect. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From milamberspace at gmail.com Sun May 31 18:57:26 2020 From: milamberspace at gmail.com (Milamber) Date: Sun, 31 May 2020 19:57:26 +0100 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> Message-ID: <4de35079-d19f-855d-55d7-7d93a3a291b0@gmail.com> On 5/31/20 6:25 PM, Matt Johnson-Pint wrote: > Forgive me if this is in any way ignorant, but why must the DST > transitions align so precisely with Ramadan? Because, during the Ramadan, the Muslims don't eat/drink from the sunrise to the sundown, so in Morocco with a GMT+1 timezone, the first lunch of the day will be near 08:30 pm (named 'Ftour' - Breakfast). So the people (and government) prefer switch back to GMT+0 to have the first lunch earlier during this month. > Would it not be sufficient if the dates for the time change were > predictable as long as the switch to GMT occurred sometime before the > start of Ramadan and the switch back to GMT+1 occurred sometime after? > Is there a political, social, or religious reason why they must be so > exactly aligned? > > -Matt > ------------------------------------------------------------------------ > *From:* tz on behalf of Milamber > > *Sent:* Sunday, May 31, 2020 7:03:50 AM > *To:* Florian Weimer ; Paul Eggert > *Cc:* Time zone mailing list > *Subject:* Re: [tz] FW: [Ext] The TZ Coordination > > > On 5/31/20 12:09 PM, Florian Weimer wrote: >> * Paul Eggert: >> >>> On 5/30/20 7:00 AM, Florian Weimer wrote: >>>>> Would this be a good opportunity to engage with the government of Morocco >>>>> to encourage them to give more warning? >>>> My understanding is that at present, they don't know themselves in >>>> advance. >>> Yes, I think you're right. >>> >>>> They would have to redefine the criteria to something based >>>> exclusively on astronomical calculations >>> That shouldn't be necessary, as they're using a conservative >>> approximation; that is, it's OK if their approximation is a bit off >>> because all they need to do is to bracket the actual Ramadan rather >>> than predict its Gregorian dates exactly. If they had an algorithm >>> they could publish it and we could use it. And it would be >>> technically feasible for them to have an algorithm; see the >>> Morocco-prediction code in the tzdb 'africa' file for an example >>> algorithm. >> It looks like the algorithm predicted correctly the data of Eid >> al-Fitr as 24 May, but the derivation of the end date from that is >> suspicious. I think it would make more sense if the time change does >> not happen on Eid itself. > > > In Morocco (where I live), the end of Ramadan (arabic month) is follow > by the Eid al-Fitr, and concretely it's 1 or 2 day off for the people > (with traditional visiting of family, big lunches/diners, etc.). So > for this year the astronomical calculations don't include the > following 2 day off in the calc. This 2 days have fall in a > Sunday/Monday, so it's not acceptable by people to have a time shift > during these 2 day off. > > Perhaps, you can modify the (predict) rules for next years : if the > end of Ramadan is a (probable) Friday or Saturday (and so the 2 day > off is on a weekend), the next time shift will be the next weekend. > > > > >> A rule like this would ensure that Eid >> still uses the same time as Ramadan in every year, which is likely >> what people expect. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Sun May 31 21:53:06 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Sun, 31 May 2020 15:53:06 -0600 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <4de35079-d19f-855d-55d7-7d93a3a291b0@gmail.com> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> <4de35079-d19f-855d-55d7-7d93a3a291b0@gmail.com> Message-ID: <46097ac8-cb57-0b3c-7e87-ca87deb5b8e7@SystematicSw.ab.ca> There is also the Eid al-Fitr festival at the start of the next month Shawwal which may last from 1-5 days, during which for some reason they typically also do not want a time change, although I would think that an opportune period. On 2020-05-31 12:57, Milamber wrote: > On 5/31/20 6:25 PM, Matt Johnson-Pint wrote: >> Forgive me if this is in any way ignorant, but why must the DST transitions >> align so precisely with Ramadan?? > Because, during the Ramadan, the Muslims don't eat/drink from the sunrise to the > sundown, so in Morocco with a GMT+1 timezone, the first lunch of the day will be > near 08:30 pm (named 'Ftour' - Breakfast). So the people (and government) prefer > switch back to GMT+0 to have the first lunch earlier during this month. >> Would it not be sufficient if the dates for the time change were predictable >> as long as the switch to GMT occurred sometime before the start of Ramadan and >> the switch back to GMT+1 occurred sometime after?? Is there a political, >> social, or religious reason why they must be so exactly aligned? >> On Sunday, May 31, 2020 7:03:50 AM, Milamber wrote: >> On 5/31/20 12:09 PM, Florian Weimer wrote: >>>> On 5/30/20 7:00 AM, Florian Weimer wrote: >>>>>> Would this be a good opportunity to engage with the government of Morocco >>>>>> to encourage them to give more warning? >>>>> My understanding is that at present, they don't know themselves in >>>>> advance. >>>> Yes, I think you're right. >>>> >>>>> They would have to redefine the criteria to something based >>>>> exclusively on astronomical calculations >>>> That shouldn't be necessary, as they're using a conservative >>>> approximation; that is, it's OK if their approximation is a bit off >>>> because all they need to do is to bracket the actual Ramadan rather >>>> than predict its Gregorian dates exactly. If they had an algorithm >>>> they could publish it and we could use it. And it would be >>>> technically feasible for them to have an algorithm; see the >>>> Morocco-prediction code in the tzdb 'africa' file for an example >>>> algorithm. >>> It looks like the algorithm predicted correctly the data of Eid >>> al-Fitr as 24 May, but the derivation of the end date from that is >>> suspicious. I think it would make more sense if the time change does >>> not happen on Eid itself. >> >> >> In Morocco (where I live), the end of Ramadan (arabic month) is follow by the >> Eid al-Fitr, and concretely it's 1 or 2 day off for the people (with >> traditional visiting of family, big lunches/diners, etc.). So for this year >> the astronomical calculations don't include the following 2 day off in the >> calc. This 2 days have fall in a Sunday/Monday, so it's not acceptable by >> people to have a time shift during these 2 day off. >> >> Perhaps, you can modify the (predict) rules for next years : if the end of >> Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a >> weekend), the next time shift will be the next weekend. >> >> >> >> >>> A rule like this would ensure that Eid >>> still uses the same time as Ramadan in every year, which is likely >>> what people expect. >>> >> > -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From eggert at cs.ucla.edu Sun May 31 22:23:27 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 31 May 2020 15:23:27 -0700 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> Message-ID: <39bf26a9-6143-5937-f890-2afcda21e059@cs.ucla.edu> On 5/31/20 7:03 AM, Milamber wrote: > Perhaps, you can modify the (predict) rules for next years : if the end of > Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a > weekend), the next time shift will be the next weekend. Thanks for the info. I installed the attached patch to change the predictions accordingly. Of course these predictions are somewhat fanciful if the Moroccan government itself doesn't know when the transitions will be. -------------- next part -------------- From e30fe68d4448a79d8ac95bf6ae81bb344328eb3c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 31 May 2020 15:17:11 -0700 Subject: [PATCH] Predict Morocco spring-forward after Eid al-Fitr MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit (Thanks to Milamber.) * NEWS: Mention this. * africa (Morocco): Change ?1+? to ?+ 2? in the commented-out code, and alter the prdicted rules accordingly for 2023-2085. --- NEWS | 7 +++++++ africa | 45 +++++++++++++++++++++++++++++---------------- 2 files changed, 36 insertions(+), 16 deletions(-) diff --git a/NEWS b/NEWS index ac491e1..8362dcc 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,13 @@ News for the tz database Unreleased, experimental changes + Changes to future timestamps + + Morocco's spring-forward after Ramadan is now predicted to occur + no sooner than two days after Ramadan, instead of one day. + (Thanks to Milamber.) The first altered prediction is for 2023, + now predicted to spring-forward on April 30 instead of April 23. + Changes to code The undocumented and ineffective tzsetwall function has been diff --git a/africa b/africa index 724744f..5d3beb0 100644 --- a/africa +++ b/africa @@ -875,17 +875,30 @@ Zone Indian/Mauritius 3:50:00 - LMT 1907 # Port Louis # https://maroc-diplomatique.net/maroc-le-retour-a-lheure-gmt-est-prevu-dimanche-prochain/ # http://aujourdhui.ma/actualite/gmt1-retour-a-lheure-normale-dimanche-prochain-1 # -# From Paul Eggert (2020-04-14): +# From Milamber (2020-05-31) +# In Morocco (where I live), the end of Ramadan (Arabic month) is followed by +# the Eid al-Fitr, and concretely it's 1 or 2 day offs for the people (with +# traditional visiting of family, big lunches/dinners, etc.). So for this +# year the astronomical calculations don't include the following 2 days off in +# the calc. These 2 days fall in a Sunday/Monday, so it's not acceptable by +# people to have a time shift during these 2 days off. Perhaps you can modify +# the (predicted) rules for next years: if the end of Ramadan is a (probable) +# Friday or Saturday (and so the 2 days off are on a weekend), the next time +# shift will be the next weekend. +# +# From Paul Eggert (2020-05-31): # For now, guess that in the future Morocco will fall back at 03:00 # the last Sunday before Ramadan, and spring forward at 02:00 the -# first Sunday after the day after Ramadan. To implement this, -# transition dates for 2021 through 2087 were determined by running -# the following program under GNU Emacs 26.3. -# (let ((islamic-year 1442)) +# first Sunday after two days after Ramadan. To implement this, +# transition dates and times for 2019 through 2087 were determined by +# running the following program under GNU Emacs 26.3. (This algorithm +# also produces the correct transition dates for 2016 through 2018, +# though the times differ due to Morocco's time zone change in 2018.) +# (let ((islamic-year 1440)) # (require 'cal-islam) # (while (< islamic-year 1511) # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year))) -# (b (1+ (calendar-islamic-to-absolute (list 10 1 islamic-year)))) +# (b (+ 2 (calendar-islamic-to-absolute (list 10 1 islamic-year)))) # (sunday 0)) # (while (/= sunday (mod (setq a (1- a)) 7))) # (while (/= sunday (mod b 7)) @@ -951,7 +964,7 @@ Rule Morocco 2021 only - May 16 2:00 0 - Rule Morocco 2022 only - Mar 27 3:00 -1:00 - Rule Morocco 2022 only - May 8 2:00 0 - Rule Morocco 2023 only - Mar 19 3:00 -1:00 - -Rule Morocco 2023 only - Apr 23 2:00 0 - +Rule Morocco 2023 only - Apr 30 2:00 0 - Rule Morocco 2024 only - Mar 10 3:00 -1:00 - Rule Morocco 2024 only - Apr 14 2:00 0 - Rule Morocco 2025 only - Feb 23 3:00 -1:00 - @@ -967,7 +980,7 @@ Rule Morocco 2029 only - Feb 18 2:00 0 - Rule Morocco 2029 only - Dec 30 3:00 -1:00 - Rule Morocco 2030 only - Feb 10 2:00 0 - Rule Morocco 2030 only - Dec 22 3:00 -1:00 - -Rule Morocco 2031 only - Jan 26 2:00 0 - +Rule Morocco 2031 only - Feb 2 2:00 0 - Rule Morocco 2031 only - Dec 14 3:00 -1:00 - Rule Morocco 2032 only - Jan 18 2:00 0 - Rule Morocco 2032 only - Nov 28 3:00 -1:00 - @@ -983,7 +996,7 @@ Rule Morocco 2036 only - Nov 23 2:00 0 - Rule Morocco 2037 only - Oct 4 3:00 -1:00 - Rule Morocco 2037 only - Nov 15 2:00 0 - Rule Morocco 2038 only - Sep 26 3:00 -1:00 - -Rule Morocco 2038 only - Oct 31 2:00 0 - +Rule Morocco 2038 only - Nov 7 2:00 0 - Rule Morocco 2039 only - Sep 18 3:00 -1:00 - Rule Morocco 2039 only - Oct 23 2:00 0 - Rule Morocco 2040 only - Sep 2 3:00 -1:00 - @@ -999,7 +1012,7 @@ Rule Morocco 2044 only - Aug 28 2:00 0 - Rule Morocco 2045 only - Jul 9 3:00 -1:00 - Rule Morocco 2045 only - Aug 20 2:00 0 - Rule Morocco 2046 only - Jul 1 3:00 -1:00 - -Rule Morocco 2046 only - Aug 5 2:00 0 - +Rule Morocco 2046 only - Aug 12 2:00 0 - Rule Morocco 2047 only - Jun 23 3:00 -1:00 - Rule Morocco 2047 only - Jul 28 2:00 0 - Rule Morocco 2048 only - Jun 7 3:00 -1:00 - @@ -1015,7 +1028,7 @@ Rule Morocco 2052 only - Jun 2 2:00 0 - Rule Morocco 2053 only - Apr 13 3:00 -1:00 - Rule Morocco 2053 only - May 25 2:00 0 - Rule Morocco 2054 only - Apr 5 3:00 -1:00 - -Rule Morocco 2054 only - May 10 2:00 0 - +Rule Morocco 2054 only - May 17 2:00 0 - Rule Morocco 2055 only - Mar 28 3:00 -1:00 - Rule Morocco 2055 only - May 2 2:00 0 - Rule Morocco 2056 only - Mar 12 3:00 -1:00 - @@ -1031,7 +1044,7 @@ Rule Morocco 2060 only - Mar 7 2:00 0 - Rule Morocco 2061 only - Jan 16 3:00 -1:00 - Rule Morocco 2061 only - Feb 27 2:00 0 - Rule Morocco 2062 only - Jan 8 3:00 -1:00 - -Rule Morocco 2062 only - Feb 12 2:00 0 - +Rule Morocco 2062 only - Feb 19 2:00 0 - Rule Morocco 2062 only - Dec 31 3:00 -1:00 - Rule Morocco 2063 only - Feb 4 2:00 0 - Rule Morocco 2063 only - Dec 16 3:00 -1:00 - @@ -1047,7 +1060,7 @@ Rule Morocco 2067 only - Dec 11 2:00 0 - Rule Morocco 2068 only - Oct 21 3:00 -1:00 - Rule Morocco 2068 only - Dec 2 2:00 0 - Rule Morocco 2069 only - Oct 13 3:00 -1:00 - -Rule Morocco 2069 only - Nov 17 2:00 0 - +Rule Morocco 2069 only - Nov 24 2:00 0 - Rule Morocco 2070 only - Oct 5 3:00 -1:00 - Rule Morocco 2070 only - Nov 9 2:00 0 - Rule Morocco 2071 only - Sep 20 3:00 -1:00 - @@ -1063,7 +1076,7 @@ Rule Morocco 2075 only - Sep 15 2:00 0 - Rule Morocco 2076 only - Jul 26 3:00 -1:00 - Rule Morocco 2076 only - Sep 6 2:00 0 - Rule Morocco 2077 only - Jul 18 3:00 -1:00 - -Rule Morocco 2077 only - Aug 22 2:00 0 - +Rule Morocco 2077 only - Aug 29 2:00 0 - Rule Morocco 2078 only - Jul 10 3:00 -1:00 - Rule Morocco 2078 only - Aug 14 2:00 0 - Rule Morocco 2079 only - Jun 25 3:00 -1:00 - @@ -1073,13 +1086,13 @@ Rule Morocco 2080 only - Jul 21 2:00 0 - Rule Morocco 2081 only - Jun 1 3:00 -1:00 - Rule Morocco 2081 only - Jul 13 2:00 0 - Rule Morocco 2082 only - May 24 3:00 -1:00 - -Rule Morocco 2082 only - Jun 28 2:00 0 - +Rule Morocco 2082 only - Jul 5 2:00 0 - Rule Morocco 2083 only - May 16 3:00 -1:00 - Rule Morocco 2083 only - Jun 20 2:00 0 - Rule Morocco 2084 only - Apr 30 3:00 -1:00 - Rule Morocco 2084 only - Jun 11 2:00 0 - Rule Morocco 2085 only - Apr 22 3:00 -1:00 - -Rule Morocco 2085 only - May 27 2:00 0 - +Rule Morocco 2085 only - Jun 3 2:00 0 - Rule Morocco 2086 only - Apr 14 3:00 -1:00 - Rule Morocco 2086 only - May 19 2:00 0 - Rule Morocco 2087 only - Mar 30 3:00 -1:00 - -- 2.25.4 From eggert at cs.ucla.edu Fri May 1 18:51:49 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 1 May 2020 11:51:49 -0700 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: On 5/1/20 8:49 AM, Sergio Bonfiglio wrote: > https://timezonedb.com/ tz-link.html mentions TimeZoneDB under "Time zone boundaries" but it'd be good to also mention their CSV and SQL downloads. I installed the attached proposed patch to try to do that. > in Italy there are 3 zones, not only ROME but also Palermo (Sicily island > complete) and Cagliari (Sardinia island complete), which differ from each > other, also if slightly in time. > How can I add these two zones to the data ? Because these zones are identical to Europe/Rome for timestamps after 1970, they're out of scope for tzdb proper . However, we do have a file 'backzone' for out-of-scope data (this file is not normally used in tzdb installations). So you can send in a patch for that file if you like, preferably in 'git format-patch' form. See Europe/Belfast for an example of what might appear in 'backzone'. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Mention-TimeZoneDB-s-CSV-and-SQL-files.patch Type: text/x-patch Size: 1948 bytes Desc: not available URL: From eggert at cs.ucla.edu Fri May 1 20:26:19 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 1 May 2020 13:26:19 -0700 Subject: [tz] [PROPOSED] More Ruthenia replacement Message-ID: <20200501202619.31323-1-eggert@cs.ucla.edu> This follows up on an earlier patch in March, which replaced ?Ruthenia? with ?Transcarpathia? but missed a couple of instances. * europe: Ruthenia?Transcarpathia in commentary here, too. * theory.html: Switch to Europe/Prague as a more easily-understood example. --- europe | 2 +- theory.html | 10 ++++------ 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/europe b/europe index 5593c60..91949d6 100644 --- a/europe +++ b/europe @@ -3983,7 +3983,7 @@ Zone Europe/Kiev 2:02:04 - LMT 1880 2:00 1:00 EEST 1991 Sep 29 3:00 2:00 E-Eur EE%sT 1995 2:00 EU EE%sT -# Ruthenia used CET 1990/1991. +# Transcarpathia used CET 1990/1991. # "Uzhhorod" is the transliteration of the Rusyn/Ukrainian pronunciation, but # "Uzhgorod" is more common in English. Zone Europe/Uzhgorod 1:29:12 - LMT 1890 Oct diff --git a/theory.html b/theory.html index c0e6f02..ffa3b4d 100644 --- a/theory.html +++ b/theory.html @@ -115,17 +115,15 @@ Each timezone has a name that uniquely identifies the timezone. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like -"Ruthenia" instead of the timezone name "Europe/Uzhgorod". +"Czech Republic" instead of the timezone name "Europe/Prague". If geolocation information is available, a selection interface can locate the user on a timezone map or prioritize names that are geographically close. For an example selection interface, see the tzselect program in the tz code. -The Unicode Common Locale Data +The Unicode Common Locale Data Repository contains data that may be useful for other selection -interfaces; it maps timezone names like Europe/Uzhgorod -to CLDR names like uauzh which are in turn mapped to -locale-dependent strings like "Uzhhorod", "Ungv?r", "???????", and -"?????". +interfaces; it maps timezone names like Europe/Prague to +locale-dependent strings like "Prague", "Praha", "?????", and "???".

-- 2.17.1 From reecestewart550 at gmail.com Fri May 1 20:58:01 2020 From: reecestewart550 at gmail.com (Reece Stewart) Date: Sat, 2 May 2020 06:58:01 +1000 Subject: [tz] tz Digest, Vol 104, Issue 1 In-Reply-To: References: Message-ID: Stop sending me should your fucken dogs On Fri., 1 May 2020, 10:00 pm , wrote: > Send tz mailing list submissions to > tz at iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request at iana.org > > You can reach the person managing the list at > tz-owner at iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. Database available in other formats (Sergio Bonfiglio) > 2. Re: Database available in other formats (Paul Eggert) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Apr 2020 17:12:55 +0200 > From: Sergio Bonfiglio > To: tz at iana.org > Subject: [tz] Database available in other formats > Message-ID: > < > CANCwfxiVBnHPUawqZxWEKU+W89PWxL0SNRUXAMLgX1iMTMUF7Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Sirs, > > First thig first a big THANK YOU for your invaluable work. > I was overwhelmed by the complexity of your database, because it requires > also external pieces of code to be safely read. > I was wondering if does exist the database in different formats that may be > larger but more readable and easy usable. > An SQL database could be really "for everyone", because can be queried by > everything from everywhere by any language. > If I may make a humble suggestion, a JD date in floating format that equips > any record with the initial and final date of the rule/event could be of > great help. > With a single query, one could recall all the records that pertain a > certain moment in time also with different and overlapping rules. > Thanks for any reply and thank for your work that is making me sweat the > classical " seven shirts". > Stay well > > Sergio Bonfiglio > ITALY > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mm.icann.org/pipermail/tz/attachments/20200428/1489fee1/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 30 Apr 2020 13:39:06 -0700 > From: Paul Eggert > To: Sergio Bonfiglio > Cc: Time zone mailing list > Subject: Re: [tz] Database available in other formats > Message-ID: > Content-Type: text/plain; charset=utf-8 > > On 4/28/20 8:12 AM, Sergio Bonfiglio wrote: > > > I was overwhelmed by the complexity of your database, because it requires > > also external pieces of code to be safely read. > > Yes, it's in its own .zi format. Typically I edit it with a text editor so > I > suppose that counts as an external piece of code. Most people either do > that, or > process it with the code supplied as part of tzdb, or use one of the > already-written tz compilers > . Perhaps one of > those > will work for you. > > > An SQL database could be really "for everyone", because can be queried by > > everything from everywhere by any language. > > MariaDB, MySQL, and Oracle Database use tzdb in some form; perhaps they're > already doing something along the lines of what you're asking for. > > > If I may make a humble suggestion, a JD date in floating format that > equips > > any record with the initial and final date of the rule/event could be of > > great help. > > JD should be relatively easy to generate automatically from the existing > format. > I doubt whether the source data should have JD directly, though, as JD is > inconvenient for humans and anyway the .zi format is now read by so many > programs that any changes to it would need to be carefully considered and > justified. But JD could be good for database queries, along the lines of > your > suggestion. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tz mailing list > tz at iana.org > https://mm.icann.org/mailman/listinfo/tz > > _______________________________________________ > By submitting your personal data, you consent to the processing of your > personal data for purposes of subscribing to this mailing list accordance > with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and > the website Terms of Service (https://www.icann.org/privacy/tos). You can > visit the Mailman link above to change your membership status or > configuration, including unsubscribing, setting digest-style delivery or > disabling delivery altogether (e.g., for a vacation), and so on. > > ------------------------------ > > End of tz Digest, Vol 104, Issue 1 > ********************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonfiglio.sergio at gmail.com Fri May 1 15:49:07 2020 From: bonfiglio.sergio at gmail.com (Sergio Bonfiglio) Date: Fri, 1 May 2020 17:49:07 +0200 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: Dear Paul, thanks for the reply. I have found that there could be some versions already available of the TZ database that could suit my needs. In order to make a due reply to your suggestions I'd tell something about your responses and I'd like too to submit you some topics that I need to confront with. The first topic is this: the UNIX date that is supported in many compilers has some limitation in order to the dates preceding Jan 1 1970. The second topic is that some of the compilers you (greatly) list onto your page are not updated at the last version of data, like for instance the Delphi version - right the one I'd like to use - which is - strange to say - includes the data WITHIN the code, that is something really against the most simple rules of Information Technology that is to keep data separated from the code. So for what this is the solution of this problem I think I will go to some other resource, that is another that I haven't found listed into your page (unless I have resoundingly missed it) that is this one: https://timezonedb.com/ These great guys provide a MySQL version of the TZ database that seems also up-to-date (I have to check it out but it is promising) and I think you should nicely include this resource into your list (unless, I repeat, I have missed it and this is just in the list already. In this case I apologize for that). I have an idea about making a software to keep the TZ database updated. I will talk you in the future If I decide to carry on this work. The third issue is what I have with Italian zones listed in the TZ, because as you correctly state in the description notes of the "europe" file, In Italy there are 3 zones, not only ROME but also Palermo (Sicily island complete) and Cagliari (Sardinia island complete), which differ from each other, also if slightly in time. How can I add these two zones to the data ? May I kindly ask you to include these two zones in some the future releases of the database ? Thanks again for your great help and your invaluable work. Sergio Bonfiglio Il giorno gio 30 apr 2020 alle ore 22:39 Paul Eggert ha scritto: > On 4/28/20 8:12 AM, Sergio Bonfiglio wrote: > > > I was overwhelmed by the complexity of your database, because it requires > > also external pieces of code to be safely read. > > Yes, it's in its own .zi format. Typically I edit it with a text editor so > I > suppose that counts as an external piece of code. Most people either do > that, or > process it with the code supplied as part of tzdb, or use one of the > already-written tz compilers > . Perhaps one of > those > will work for you. > > > An SQL database could be really "for everyone", because can be queried by > > everything from everywhere by any language. > > MariaDB, MySQL, and Oracle Database use tzdb in some form; perhaps they're > already doing something along the lines of what you're asking for. > > > If I may make a humble suggestion, a JD date in floating format that > equips > > any record with the initial and final date of the rule/event could be of > > great help. > > JD should be relatively easy to generate automatically from the existing > format. > I doubt whether the source data should have JD directly, though, as JD is > inconvenient for humans and anyway the .zi format is now read by so many > programs that any changes to it would need to be carefully considered and > justified. But JD could be good for database queries, along the lines of > your > suggestion. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonfiglio.sergio at gmail.com Fri May 1 21:13:56 2020 From: bonfiglio.sergio at gmail.com (Sergio Bonfiglio) Date: Fri, 1 May 2020 23:13:56 +0200 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: Thanks, I'll check them out. Sergio Il giorno ven 1 mag 2020 alle ore 20:51 Paul Eggert ha scritto: > On 5/1/20 8:49 AM, Sergio Bonfiglio wrote: > > > https://timezonedb.com/ > > tz-link.html mentions TimeZoneDB under "Time zone boundaries" but it'd be > good > to also mention their CSV and SQL downloads. I installed the attached > proposed > patch to try to do that. > > > in Italy there are 3 zones, not only ROME but also Palermo (Sicily island > > complete) and Cagliari (Sardinia island complete), which differ from each > > other, also if slightly in time. > > How can I add these two zones to the data ? > > Because these zones are identical to Europe/Rome for timestamps after 1970, > they're out of scope for tzdb proper > . However, we do have > a file > 'backzone' for out-of-scope data (this file is not normally used in tzdb > installations). So you can send in a patch for that file if you like, > preferably > in 'git format-patch' form. See Europe/Belfast for an example of what might > appear in 'backzone'. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eggert at cs.ucla.edu Sun May 3 22:28:05 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 3 May 2020 15:28:05 -0700 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: <94d4ff4f-7529-76e3-6577-df430f1d46a2@cs.ucla.edu> On 5/3/20 5:48 AM, Sergio Bonfiglio wrote: > I don't know what to do with the file 0001-Mention.... etc. that you sent > me. > Must I apply to a git clone or something ? You could do that, yes. Or you could simply clone the current development version , as it has the patch already applied. Eventually the development version should evolve into the next release. From andrew at tao11.riddles.org.uk Mon May 4 02:36:20 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Mon, 04 May 2020 03:36:20 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" Message-ID: <877dxs36bj.fsf@news-spur.riddles.org.uk> In a post on this list on Nov 24 last, Garret Wollman said regarding FreeBSD's c.1994 change (now reversed) to not install "backward": >> I chose not to install the "backward" zones in the hope that this >> would more securely deprecate the then-recently-obsoleted old-style >> names like "US/Eastern", and then maybe they could be completely >> removed from the distribution if other downstream consumers (only a >> few operating systems at that point, no language runtimes) would do >> likewise. >> Unfortunately, these ancient compatibility links never got deleted, >> so "backward" now contains a mix of ancient and more recent >> compatibility links, and users are still using them (or being told >> to use them by documentation that should have been updated decades >> ago). The obvious way to resolve this would be to split "backward" into two: one file containing aliases that were once regarded as canonical names (or at least names consistent with current naming theory) but were then renamed (e.g. the recent example of Godthab -> Nuuk), the other containing all the ancient stuff that never conformed to the current style (such as "W-SU", "Poland", "GB-Eire", "US/Eastern" etc.). One way to do this might be to set a cutoff date, for which the 2000a data release seems like a good choice, and retain only the zones changed since then in "backward", moving the remainder to a new "deprecated" category. Another way would be to reserve "backward" for zones that have appeared in zone.tab at any time, and move the rest to "deprecated". It turns out that these two methods give almost exactly the same results, with only two exceptions: America/Ensenada was in "backward" before 2000 going by the SCM history, but existed in zone.tab until 2010; and Asia/Ulan_Bator was added to "backward" and removed from zone.tab in the 2000a release. This suggests that the zone.tab criterion is a slightly better one. (One further exception should be made: the link from Etc/UTC to UTC is in widespread use and should probably be moved to "etcetera" alongside the similar "GMT" link. Otherwise it should stay in "backward". This change already exists in FreeBSD, where all "GMT" defaults have been changed to "UTC" at some point.) Split this way, the list of links in "backward" would become (posted in plain text here for readability, I can submit in patch form if needed) as follows: Link Africa/Nairobi Africa/Asmera Link Africa/Abidjan Africa/Timbuktu Link America/Argentina/Catamarca America/Argentina/ComodRivadavia Link America/Argentina/Buenos_Aires America/Buenos_Aires Link America/Argentina/Catamarca America/Catamarca Link America/Atikokan America/Coral_Harbour Link America/Argentina/Cordoba America/Cordoba Link America/Tijuana America/Ensenada Link America/Nuuk America/Godthab Link America/Indiana/Indianapolis America/Indianapolis Link America/Argentina/Jujuy America/Jujuy Link America/Kentucky/Louisville America/Louisville Link America/Argentina/Mendoza America/Mendoza Link America/Toronto America/Montreal Link America/Rio_Branco America/Porto_Acre Link America/Argentina/Cordoba America/Rosario Link America/Tijuana America/Santa_Isabel Link America/Denver America/Shiprock Link Pacific/Auckland Antarctica/South_Pole Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Kolkata Asia/Calcutta Link Asia/Shanghai Asia/Chongqing Link Asia/Shanghai Asia/Chungking Link Asia/Dhaka Asia/Dacca Link Asia/Shanghai Asia/Harbin Link Asia/Urumqi Asia/Kashgar Link Asia/Kathmandu Asia/Katmandu Link Asia/Macau Asia/Macao Link Asia/Yangon Asia/Rangoon Link Asia/Ho_Chi_Minh Asia/Saigon Link Asia/Thimphu Asia/Thimbu Link Asia/Makassar Asia/Ujung_Pandang Link Asia/Ulaanbaatar Asia/Ulan_Bator Link Atlantic/Faroe Atlantic/Faeroe Link Europe/Oslo Atlantic/Jan_Mayen Link Etc/UTC Etc/UCT Link Europe/London Europe/Belfast Link Europe/Chisinau Europe/Tiraspol Link Pacific/Honolulu Pacific/Johnston Link Pacific/Pohnpei Pacific/Ponape Link Pacific/Chuuk Pacific/Truk Link Pacific/Chuuk Pacific/Yap Link Etc/UTC UTC "deprecated" would contain these links: Link America/Adak America/Atka Link America/Indiana/Indianapolis America/Fort_Wayne Link America/Indiana/Knox America/Knox_IN Link America/Port_of_Spain America/Virgin Link Asia/Jerusalem Asia/Tel_Aviv Link Australia/Sydney Australia/ACT Link Australia/Sydney Australia/Canberra Link Australia/Lord_Howe Australia/LHI Link Australia/Sydney Australia/NSW Link Australia/Darwin Australia/North Link Australia/Brisbane Australia/Queensland Link Australia/Adelaide Australia/South Link Australia/Hobart Australia/Tasmania Link Australia/Melbourne Australia/Victoria Link Australia/Perth Australia/West Link Australia/Broken_Hill Australia/Yancowinna Link America/Rio_Branco Brazil/Acre Link America/Noronha Brazil/DeNoronha Link America/Sao_Paulo Brazil/East Link America/Manaus Brazil/West Link America/Halifax Canada/Atlantic Link America/Winnipeg Canada/Central Link America/Toronto Canada/Eastern Link America/Edmonton Canada/Mountain Link America/St_Johns Canada/Newfoundland Link America/Vancouver Canada/Pacific Link America/Regina Canada/Saskatchewan Link America/Whitehorse Canada/Yukon Link America/Santiago Chile/Continental Link Pacific/Easter Chile/EasterIsland Link America/Havana Cuba Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London GB Link Europe/London GB-Eire Link Etc/GMT GMT+0 Link Etc/GMT GMT-0 Link Etc/GMT GMT0 Link Etc/GMT Greenwich Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran Link Asia/Jerusalem Israel Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein Link Africa/Tripoli Libya Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC Link Pacific/Pago_Pago Pacific/Samoa Link Europe/Warsaw Poland Link Europe/Lisbon Portugal Link Asia/Taipei ROC Link Asia/Seoul ROK Link Asia/Singapore Singapore Link Europe/Istanbul Turkey Link Etc/UTC UCT Link America/Anchorage US/Alaska Link America/Adak US/Aleutian Link America/Phoenix US/Arizona Link America/Chicago US/Central Link America/Indiana/Indianapolis US/East-Indiana Link America/New_York US/Eastern Link Pacific/Honolulu US/Hawaii Link America/Indiana/Knox US/Indiana-Starke Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific Link Pacific/Pago_Pago US/Samoa Link Etc/UTC Universal Link Europe/Moscow W-SU Link Etc/UTC Zulu -- Andrew. From bonfiglio.sergio at gmail.com Sun May 3 12:48:51 2020 From: bonfiglio.sergio at gmail.com (Sergio Bonfiglio) Date: Sun, 3 May 2020 14:48:51 +0200 Subject: [tz] Database available in other formats In-Reply-To: References: Message-ID: Dear Paul, I don't know what to do with the file 0001-Mention.... etc. that you sent me. Must I apply to a git clone or something ? Would you apply to the official page, so you sent it to me for a sort of approval ? Excuse my ignorance, please. Sergio Il giorno ven 1 mag 2020 alle ore 20:51 Paul Eggert ha scritto: > On 5/1/20 8:49 AM, Sergio Bonfiglio wrote: > > > https://timezonedb.com/ > > tz-link.html mentions TimeZoneDB under "Time zone boundaries" but it'd be > good > to also mention their CSV and SQL downloads. I installed the attached > proposed > patch to try to do that. > > > in Italy there are 3 zones, not only ROME but also Palermo (Sicily island > > complete) and Cagliari (Sardinia island complete), which differ from each > > other, also if slightly in time. > > How can I add these two zones to the data ? > > Because these zones are identical to Europe/Rome for timestamps after 1970, > they're out of scope for tzdb proper > . However, we do have > a file > 'backzone' for out-of-scope data (this file is not normally used in tzdb > installations). So you can send in a patch for that file if you like, > preferably > in 'git format-patch' form. See Europe/Belfast for an example of what might > appear in 'backzone'. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elseifthen at gmx.com Mon May 4 16:02:16 2020 From: elseifthen at gmx.com (J William Piggott) Date: Mon, 4 May 2020 12:02:16 -0400 (EDT) Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <877dxs36bj.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> Message-ID: On Mon, 4 May 2020, Andrew Gierth wrote: ... >8 > Another way would be to reserve "backward" for zones that have appeared > in zone.tab at any time, and move the rest to "deprecated". > ... >8 > > (One further exception should be made: the link from Etc/UTC to UTC is I tried to get UTC added to zone.tab back on 9 Mar 2016; but received a lot of push back. Everyone seemed to be hung up on the use-case definition that UTC is an enigma, existing everywhere and nowhere at the same time. Heads exploded at the thought of UTC having a geographic connection, which it does. Enumerating that connection in no way inhibits the enigma use-case, IMO. It is incomprehensible to me that a database built around a single reference, makes that reference unreachable from within, for lack of better a term, its API. There are many projects, both hardware and software, that use zone.tab as the Time Zone Database API. For these projects, if it's not in zone.tab it does not exist. For example, in my GPS hardware I'm forced to use Reykjavik for UTC. The geographic tie is just a API lookup index, any zone can be used at any location. If I'm in Tokyo, I can still use the New York zone, even though that zone has a North American geographic tie. UTC having a geographic tie doesn't in anyway inhibit its global use. Another complaint was that a single locale is not a zone. The DB already contains single point 'zones' in Antarctica, which are in zone.tab. ... >8 > -- > Andrew. > From Brian.Inglis at SystematicSw.ab.ca Mon May 4 23:41:23 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Mon, 4 May 2020 17:41:23 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <877dxs36bj.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> Message-ID: On 2020-05-03 20:36, Andrew Gierth wrote: > (One further exception should be made: the link from Etc/UTC to UTC is > in widespread use and should probably be moved to "etcetera" alongside > the similar "GMT" link. Otherwise it should stay in "backward". This > change already exists in FreeBSD, where all "GMT" defaults have been > changed to "UTC" at some point.) It is not clear what you mean by saying FreeBSD changed GMT defaults to UTC at some point. There is a subtle distinction here as legal time in English common law derived legal systems is established by precedent, as GMT based mean solar time, not on the ITU time scale based on the SI second with leap seconds UTC. The difference between the legal basis of time derived from solar observations and calculations, and the practice of disseminating time derived from UTC, has not yet been tested in law, so dropping any distinction could be problematic, especially now, with GB divorcing EU, to give English common law renewed hegemony over GB laws in devolved assemblies, except for NI as regards time. The statute in primary effect in England, Wales, and Scotland is still: http://statutes.org.uk/site/the-statutes/nineteenth-century/1880-43-44-victoria-c-9-definition-of-time-act/ and it also currently pertains to NI, Isle of Man, the Channel Islands of Jersey, Guernsey, Alderney, Sark; and by reference to GMT (often in local equivalents of Interpretation, or Definition of Time, Acts), also to Ireland, Belgium, Portugal, Canaries, Iceland, Faeroes, Canada, and a number of African former territories of the British Empire and current members of the Commonwealth (of Nations). -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. From andrew at tao11.riddles.org.uk Tue May 5 00:26:22 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Tue, 05 May 2020 01:26:22 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: (Brian Inglis's message of "Mon, 4 May 2020 17:41:23 -0600") References: <877dxs36bj.fsf@news-spur.riddles.org.uk> Message-ID: <87zhan9ryy.fsf@news-spur.riddles.org.uk> >>>>> "Brian" == Brian Inglis writes: >> (One further exception should be made: the link from Etc/UTC to UTC >> is in widespread use and should probably be moved to "etcetera" >> alongside the similar "GMT" link. Otherwise it should stay in >> "backward". This change already exists in FreeBSD, where all "GMT" >> defaults have been changed to "UTC" at some point.) Brian> It is not clear what you mean by saying FreeBSD changed GMT Brian> defaults to UTC at some point. I mean that where the tzcode uses "GMT" as a default zone name or abbreviation in the absence of data, FreeBSD uses "UTC" (and has since 2004). e.g. with no /etc/localtime file, % env -u TZ date Tue 5 May 2020 00:00:37 UTC (To the best of my knowledge there are no reference clocks available to which one could synchronize in order to use a mean solar time, so your argument seems to me to support this choice.) -- Andrew. From eggert at cs.ucla.edu Tue May 5 00:46:52 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 4 May 2020 17:46:52 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87zhan9ryy.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> On 5/4/20 5:26 PM, Andrew Gierth wrote: > I mean that where the tzcode uses "GMT" as a default zone name or > abbreviation in the absence of data, FreeBSD uses "UTC" (and has since > 2004). It would be easy enough to replace the "GMT" in localtime.c and the "TZ=GMT0" in date.c with their UTC counterparts. This issue is somewhat independent of what's in 'backward', though, because this stuff is hard-coded in tzcode and tzdata's contents don't affect it. Getting back to the main point, I'm not sure it's worth deprecating links like 'US/Pacific' any time soon, as so many people use them and their cost is not great. It might be worth coming up with some division of the existing 'backward' file (e.g., recently-backward names vs older-backward names), although I'm not sure what that would look like. I suppose we could have a comment associated with each name saying when it became backward, though that'd increase maintenance hassle. From philip at trouble.is Tue May 5 01:57:19 2020 From: philip at trouble.is (Philip Paeps) Date: Tue, 05 May 2020 09:57:19 +0800 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> Message-ID: <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> On 2020-05-05 08:46:52 (+0800), Paul Eggert wrote: > Getting back to the main point, I'm not sure it's worth deprecating > links like 'US/Pacific' any time soon, as so many people use them and > their cost is not great. As far as FreeBSD is concerned: since we haven't installed 'US/Pacific' since ca 1994, I'm pretty sure nobody uses it. :-) Since you mention cost though: installing the backward zones increased the footprint of /usr/share/zoneinfo from about 1.8M to about 3.3M. I don't consider that worth losing sleep over in 2020. People who build systems where every megabyte counts probably don't ship /usr/share/zoneinfo in the first place. Or they can trivially patch the build system not to install backward zones. > It might be worth coming up with some division of the existing > 'backward' file (e.g., recently-backward names vs older-backward > names), although I'm not sure what that would look like. I suppose we > could have a comment associated with each name saying when it became > backward, though that'd increase maintenance hassle. Adding a comment stating when the name became backward isn't a huge additional maintenance burden. Especially since we don't move things to backward all that often. The division into backward and deprecated could be scripted based on that comment. Adding the historical comments would be a bit of work though. We could also split backward as Andrew proposes and start tagging additions to backward going forward. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From PaulGBoulder at AIM.com Tue May 5 01:58:42 2020 From: PaulGBoulder at AIM.com (Paul Gilmartin) Date: Mon, 4 May 2020 19:58:42 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87zhan9ryy.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: On 2020-05-04, at 18:26:22, Andrew Gierth wrote: > > I mean that where the tzcode uses "GMT" as a default zone name or > abbreviation in the absence of data, FreeBSD uses "UTC" (and has since > 2004). > > e.g. with no /etc/localtime file, > > % env -u TZ date > Tue 5 May 2020 00:00:37 UTC > > (To the best of my knowledge there are no reference clocks available to > which one could synchronize in order to use a mean solar time, so your > argument seems to me to support this choice.) > Do you mean mean solar time at some arbitrary precise longitude or mean solar time at the Prime Meridian? If the latter, is interpolated UT1 a close enough approximation?: https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination -- gil From andrew at tao11.riddles.org.uk Tue May 5 03:00:18 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Tue, 05 May 2020 04:00:18 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> (Philip Paeps's message of "Tue, 05 May 2020 09:57:19 +0800") References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> Message-ID: <87tv0v9jkm.fsf@news-spur.riddles.org.uk> >>>>> "Philip" == Philip Paeps writes: Philip> Since you mention cost though: installing the backward zones Philip> increased the footprint of /usr/share/zoneinfo from about 1.8M Philip> to about 3.3M. Really? Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most. Philip> Or they can trivially patch the build system not to install Philip> backward zones. Well, there used to be a build option for that in the base system, but somebody just took it out... -- Andrew. From andrew at tao11.riddles.org.uk Tue May 5 03:06:04 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Tue, 05 May 2020 04:06:04 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> (Paul Eggert's message of "Mon, 4 May 2020 17:46:52 -0700") References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> Message-ID: <87pnbj9j95.fsf@news-spur.riddles.org.uk> >>>>> "Paul" == Paul Eggert writes: Paul> Getting back to the main point, I'm not sure it's worth Paul> deprecating links like 'US/Pacific' any time soon, as so many Paul> people use them Are there any statistics on that? The US/* names are one thing, but what about the nonsense like "W-SU"? The random selection of places that get top-level entries for no readily apparent reason? If there's actual usage justification for keeping US/* specifically in backward, or making it its own compatibility file, I have no particular objection, but it doesn't justify not clearing up the rest of the mess. -- Andrew. From philip at trouble.is Tue May 5 03:16:42 2020 From: philip at trouble.is (Philip Paeps) Date: Tue, 05 May 2020 11:16:42 +0800 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87tv0v9jkm.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: On 2020-05-05 11:00:18 (+0800), Andrew Gierth wrote: > Philip Paeps wrote: >> Since you mention cost though: installing the backward zones >> increased the footprint of /usr/share/zoneinfo from about 1.8M to >> about 3.3M. > > Really? > > Installing "backward" should create only links, and therefore have > negligible effect on the size, the only real penalty being the extra > directories and entries which should be only a few blocks at most. It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely). >> Or they can trivially patch the build system not to install backward >> zones. > > Well, there used to be a build option for that in the base system, but > somebody just took it out... Easy enough to put back if someone yells about it. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From eggert at cs.ucla.edu Tue May 5 03:41:46 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 4 May 2020 20:41:46 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: On 5/4/20 8:16 PM, Philip Paeps wrote: > It looks like we install the files rather than links.? Or I've botched something > on the test machine I looked at (which is not unlikely). If you're installing files then that should get fixed. In tzdb on my Fedora 31 platform (ext4 filesystem with 4 KiB blocks), 'make install' creates a zoneinfo directory that 'du' reports consumes 1800 KiB, as opposed to the 1776 KiB consumed for the same directory with 'make BACKWARD="" install'. The 24 KiB difference comes mostly from the five extra directories implied by 'backward' (Brazil, Canada, Chile, Mexico, US) each of which consume 4 KiB; the rest comes from the larger tzdata.zi file (108 vs 112 KiB allocated, due to the extra -L lines). >>> Or they can trivially patch the build system not to install backward zones. >> >> Well, there used to be a build option for that in the base system, but >> somebody just took it out... > > Easy enough to put back if someone yells about it. Might make sense to put it back in (if only for compatibility with older FreeBSD systems where TZ='W-SU' gave you UTC :-). From eggert at cs.ucla.edu Tue May 5 03:48:36 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 4 May 2020 20:48:36 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87pnbj9j95.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <87pnbj9j95.fsf@news-spur.riddles.org.uk> Message-ID: On 5/4/20 8:06 PM, Andrew Gierth wrote: >>>>>> "Paul" == Paul Eggert writes: > > Paul> Getting back to the main point, I'm not sure it's worth > Paul> deprecating links like 'US/Pacific' any time soon, as so many > Paul> people use them > > Are there any statistics on that? > > The US/* names are one thing, but what about the nonsense like "W-SU"? I don't know of any statistics. A quick Google search suggests that TZ='US/Pacific' is far more common than TZ='W-SU'. That being said, I did find a few instances of the latter, including: http://forum.ixbt.com/topic.cgi?id=24:29252 https://github.com/rstudio/bookdown/issues/440 https://postgrespro.ru/list/thread-id/1220710 From andrew at tao11.riddles.org.uk Tue May 5 04:07:35 2020 From: andrew at tao11.riddles.org.uk (Andrew Gierth) Date: Tue, 05 May 2020 05:07:35 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: (Paul Eggert's message of "Mon, 4 May 2020 20:41:46 -0700") References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: <87imhb9gm6.fsf@news-spur.riddles.org.uk> >>>>> "Paul" == Paul Eggert writes: >>>> Or they can trivially patch the build system not to install >>>> backward zones. >>> >>> Well, there used to be a build option for that in the base system, >>> but somebody just took it out... >> >> Easy enough to put back if someone yells about it. Paul> Might make sense to put it back in (if only for compatibility Paul> with older FreeBSD systems where TZ='W-SU' gave you UTC :-). But the real point here is that we _want_ some of the backward zones - especially the ones that users may have legitimately configured with tzsetup (which reads zone.tab / zone1970.tab) in the past but which got renamed (as in the recent example of America/Godthab). The problem right now is that there isn't a way to conveniently distinguish those zones from the ones that just get in the way and cause confusion. This is why my proposal retains in the "backward" file every zone that has ever been in zone.tab. -- Andrew. From tgl at sss.pgh.pa.us Tue May 5 04:33:15 2020 From: tgl at sss.pgh.pa.us (Tom Lane) Date: Tue, 05 May 2020 00:33:15 -0400 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <87imhb9gm6.fsf@news-spur.riddles.org.uk> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> <87imhb9gm6.fsf@news-spur.riddles.org.uk> Message-ID: <22630.1588653195@sss.pgh.pa.us> Andrew Gierth writes: > But the real point here is that we _want_ some of the backward zones - > especially the ones that users may have legitimately configured with > tzsetup (which reads zone.tab / zone1970.tab) in the past but which got > renamed (as in the recent example of America/Godthab). > The problem right now is that there isn't a way to conveniently > distinguish those zones from the ones that just get in the way and cause > confusion. This is why my proposal retains in the "backward" file every > zone that has ever been in zone.tab. It's not clear to me whether your proposal includes removal of the newly "deprecated" zones from the default build rule. If it doesn't, then this is just paper-shuffling so far as many (most?) consumers of tzdata are concerned. It gets considerably more real if the proposal is to not include the "deprecated" source file in the standard Makefile build rule. Postgres, for instance, has for some time just used whatever is in the distributed tzdata.zi file. So we'd either continue to support these zones, or not, depending on what happens in the build process for that file. I don't currently have an opinion on whether changing that would be a good or bad thing ... but as far as I could see, you didn't say what you wanted to happen. regards, tom lane From sla at ucolick.org Tue May 5 05:54:29 2020 From: sla at ucolick.org (Steve Allen) Date: Mon, 4 May 2020 22:54:29 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: <20200505055429.GA31871@ucolick.org> On Mon 2020-05-04T19:58:42-0600 Paul Gilmartin via tz hath writ: > On 2020-05-04, at 18:26:22, Andrew Gierth wrote: > > (To the best of my knowledge there are no reference clocks available to > > which one could synchronize in order to use a mean solar time, so your > > argument seems to me to support this choice.) > > > Do you mean mean solar time at some arbitrary precise longitude > or mean solar time at the Prime Meridian? If the latter, is > interpolated UT1 a close enough approximation?: > https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination UT1 is not mean solar time, but it is the quantity which is conventionally recognized as mean solar time. In 1954 Sadler recognized that by its existing convention UT (not then yet named UT1) deviates from mean solar time. https://www.ucolick.org/~sla/leapsecs/Sadler1954.pdf Seago and Seidelmann explored this much more deeply in 2013 https://www.agi.com/resources/white-papers/the-mean-solar-time-origin-of-universal-time-and-u and showed how an alternative formulation might be developed if calendar days are to continue be determined by measuring rotation of the earth. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m From tgl at sss.pgh.pa.us Tue May 5 13:43:52 2020 From: tgl at sss.pgh.pa.us (Tom Lane) Date: Tue, 05 May 2020 09:43:52 -0400 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <22630.1588653195@sss.pgh.pa.us> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> <87imhb9gm6.fsf@news-spur.riddles.org.uk> <22630.1588653195@sss.pgh.pa.us> Message-ID: <18878.1588686232@sss.pgh.pa.us> I wrote: > It's not clear to me whether your proposal includes removal of the > newly "deprecated" zones from the default build rule. After further thought I've concluded that I don't like Andrew's proposal as-presented. If some zone names are moved into a new source file, what will inevitably happen is that some platforms/ repackagers will continue to support those names, while others will not --- either through conscious choice or just by forgetting to update their build recipes. That seems like a bad situation to create. Like it or not, tzdb has created a de facto standard for the set of known zone names, and it's better for a standard to be actually standard, not subject to local whims. Recall that in the other thread Andrew referred to, FreeBSD got ragged on for being the only major platform not supporting the "backward" zones. That was justifiable IMO, and I don't think that situation should be reintroduced or magnified. Thus, I think it would be better to either do nothing, or decide that these zone names are dead, and summarily remove them altogether. While the latter option would no doubt cause some pain somewhere, it's not without precedent. I compare it to the effort not so long ago to remove undocumented zone abbreviations. That did result in some push-back, but not a huge amount ... and what's more to the point for the current discussion, downstream packagers were not given any choice in the matter. In short, I don't care hugely whether these zone names live or die; but let's either kill them off everywhere or nowhere. regards, tom lane From PaulGBoulder at AIM.com Tue May 5 14:27:33 2020 From: PaulGBoulder at AIM.com (Paul Gilmartin) Date: Tue, 5 May 2020 08:27:33 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: <9AC60D5D-DAA9-4484-800F-23D20FDDDC80@AIM.com> On 2020-05-04, at 21:16:42, Philip Paeps wrote: > > On 2020-05-05 11:00:18 (+0800), Andrew Gierth wrote: >> >> >> Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most. > > It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely). > It varies. On Linux I see numerous symlinks. (Doesn't a symlink use a disk block?) On MacOS, I see neither symlinks nor multiple directory links, but many duplicate files. -- gil From john.haxby at oracle.com Tue May 5 16:46:12 2020 From: john.haxby at oracle.com (John Haxby) Date: Tue, 5 May 2020 17:46:12 +0100 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <9AC60D5D-DAA9-4484-800F-23D20FDDDC80@AIM.com> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> <9AC60D5D-DAA9-4484-800F-23D20FDDDC80@AIM.com> Message-ID: <181014FF-D1A5-4CB6-9DA8-D640F66B9BC6@oracle.com> > On 5 May 2020, at 15:27, Paul Gilmartin via tz wrote: > > On 2020-05-04, at 21:16:42, Philip Paeps wrote: >> >> On 2020-05-05 11:00:18 (+0800), Andrew Gierth wrote: >>> >>> >>> Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most. >> >> It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely). >> > It varies. > > On Linux I see numerous symlinks. (Doesn't a symlink use a disk block?) Reasonably short symlinks are stored in the inode. Links, though, are just an entry in a directory so don't occupy any additional space unless you have a few thousand of them. jch > > On MacOS, I see neither symlinks nor multiple directory links, > but many duplicate files. Disk space is cheap :) jch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: Message signed with OpenPGP URL: From Brian.Inglis at SystematicSw.ab.ca Tue May 5 18:08:38 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Tue, 5 May 2020 12:08:38 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> <71C7FF58-C2C3-4C9D-A7B1-11DC89D69D80@trouble.is> <87tv0v9jkm.fsf@news-spur.riddles.org.uk> Message-ID: <96e5d880-676c-03cf-4a59-a6556ea860df@SystematicSw.ab.ca> On 2020-05-04 21:41, Paul Eggert wrote: > On 5/4/20 8:16 PM, Philip Paeps wrote: > >> It looks like we install the files rather than links.? Or I've botched something >> on the test machine I looked at (which is not unlikely). > > If you're installing files then that should get fixed. In tzdb on my Fedora 31 > platform (ext4 filesystem with 4 KiB blocks), 'make install' creates a zoneinfo > directory that 'du' reports consumes 1800 KiB, as opposed to the 1776 KiB > consumed for the same directory with 'make BACKWARD="" install'. The 24 KiB > difference comes mostly from the five extra directories implied by 'backward' > (Brazil, Canada, Chile, Mexico, US) each of which consume 4 KiB; the rest comes > from the larger tzdata.zi file (108 vs 112 KiB allocated, due to the extra -L > lines). A number of distros seem to end up installing file copies or symbolic rather than hard links under /usr/share/zoneinfo. I created a simple shell script to check GMT link count and if not > 1, `find` all symlinks, relink symbolic as hard links, `find` all files, `sort` by size, `cmp` those of the same size, and hard `link` them if identical, with before and after summary unique and total inode, link, and file counts and sizes. For systems installing right with copies, it drops the size from three copies >4.5MB to two copies ~3.4MB; for systems installing right with symlinks, it only reduces the size of each copy by the size of the symlink paths, about 25KB/copy, but avoids the indirection access. [I became wary of tz performance, when one process on an AIX system took about 1s per naive `getenv` TZ save, `putenv` TZ set, `tzset` to load data and switch tz in a thread, and it was doing a couple of switches per transaction, depending on front end user locales. Going via the DB interface instead provided caching to speed up lookups, and minor local caching avoided lookups as much as possible.] >>>> Or they can trivially patch the build system not to install backward zones. >>> >>> Well, there used to be a build option for that in the base system, but >>> somebody just took it out... >> >> Easy enough to put back if someone yells about it. > > Might make sense to put it back in (if only for compatibility with older FreeBSD > systems where TZ='W-SU' gave you UTC :-). It would be nice to get some tzdata- alternative packages with -minimal, -tiny, -big, -full, etc. variants depending on build options, perhaps more meaningful names; similar to dict, scowl, words list packages on some distros. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From Brian.Inglis at SystematicSw.ab.ca Tue May 5 19:14:44 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Tue, 5 May 2020 13:14:44 -0600 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: On 2020-05-04 19:58, Paul Gilmartin via tz wrote: > On 2020-05-04, at 18:26:22, Andrew Gierth wrote: >> I mean that where the tzcode uses "GMT" as a default zone name or >> abbreviation in the absence of data, FreeBSD uses "UTC" (and has since >> 2004). >> e.g. with no /etc/localtime file, >> % env -u TZ date >> Tue 5 May 2020 00:00:37 UTC >> >> (To the best of my knowledge there are no reference clocks available to >> which one could synchronize in order to use a mean solar time, so your >> argument seems to me to support this choice.) >> > Do you mean mean solar time at some arbitrary precise longitude > or mean solar time at the Prime Meridian? If the latter, is > interpolated UT1 a close enough approximation?: > https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination No, as the precision of UT1 based on the Earth Rotation Angle is ms a day; UT1R has 62 smoothing terms; UT2 smoothes out seasonal variations; some variation of UT would be required to provide mean solar time at a consistent rate. NIST are still applying radio clock accuracy standards with ~ms precision, where the current norm is ~us from GPS, certainly over local LAN and even over decent remote WAN links. The older standard is adequate for MS products which require only watch-and-eyeball accuracy, but more systems are needing more accurate time. [The point may be moot, as the lawyers heading the US FCC approved the junk science from US Ligado Networks lawyers that say GNSS will not be disrupted by their terrestrial L band transmissions. Those disrupted will have to prove to US FCC lawyers that they were disrupted by US Ligado Networks transmissions. Ligado used to be LightSquared which went bankrupt when their testing proved their transmissions would disrupt GNSS. The FCC no longer requires tests, just sworn assertions from lawyers, if the lawyers approve how the physics is used!] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From sla at ucolick.org Tue May 5 21:05:08 2020 From: sla at ucolick.org (Steve Allen) Date: Tue, 5 May 2020 14:05:08 -0700 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> Message-ID: <20200505210508.GB19786@ucolick.org> On Tue 2020-05-05T13:14:44-0600 Brian Inglis hath writ: > On 2020-05-04 19:58, Paul Gilmartin via tz wrote: > > On 2020-05-04, at 18:26:22, Andrew Gierth wrote: > >> (To the best of my knowledge there are no reference clocks available to > >> which one could synchronize in order to use a mean solar time, so your > >> argument seems to me to support this choice.) > >> > > Do you mean mean solar time at some arbitrary precise longitude > > or mean solar time at the Prime Meridian? If the latter, is > > interpolated UT1 a close enough approximation?: > > https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination > > No, as the precision of UT1 based on the Earth Rotation Angle is ms a day; UT1R > has 62 smoothing terms; UT2 smoothes out seasonal variations; some variation of > UT would be required to provide mean solar time at a consistent rate. > NIST are still applying radio clock accuracy standards with ~ms precision, where > the current norm is ~us from GPS, certainly over local LAN and even over decent > remote WAN links. The UK radio broadcast time signals stopped providing GMT in 1953. Starting then they transmitted Provisional Uniform Time, PUT, which was their own forerunner version of UT2. The US radio broadcast time signals made similar changes around then. The USNO version of uniform time scale had names like N3c. So since the 1950s there has been no real-time source of mean solar time, only quartz and cesium clock time adjusted to follow that. > The older standard is adequate for MS products which require only > watch-and-eyeball accuracy, but more systems are needing more accurate time. Different sources of radio broadcast time signals did not agree to within 1 ms until 1960 when the US and UK began to coordinate their transmissions using cesium. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m From jhawk at alum.mit.edu Tue May 5 01:00:17 2020 From: jhawk at alum.mit.edu (John Hawkinson) Date: Mon, 4 May 2020 21:00:17 -0400 Subject: [tz] suggestion: split "backward" into "backward" and "deprecated" In-Reply-To: <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> References: <877dxs36bj.fsf@news-spur.riddles.org.uk> <87zhan9ryy.fsf@news-spur.riddles.org.uk> <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu> Message-ID: <20200505010017.GQ3070@alum.mit.edu> Paul Eggert wrote on Mon, 4 May 2020 at 20:46:52 EDT in <7949485f-7efc-5590-ac50-a12dfd4c7718 at cs.ucla.edu>: > Getting back to the main point, I'm not sure it's worth deprecating > links like 'US/Pacific' any time soon, as so many people use them I would strongly object to such deprecation. I realize we've set ourselves on such a path in a historical decision I disagree with, and that there's a desire not to relitigate it, but those links make a logical sense that should not be ignored. Leave those alone, please. Conservatism cautions against unnecessary churn. -- jhawk at alum.mit.edu John Hawkinson > and their cost is not great. It might be worth coming up with some > division of the existing 'backward' file (e.g., recently-backward > names vs older-backward names), although I'm not sure what that > would look like. I suppose we could have a comment associated with > each name saying when it became backward, though that'd increase > maintenance hassle. From paul at ganssle.io Wed May 13 18:19:23 2020 From: paul at ganssle.io (Paul Ganssle) Date: Wed, 13 May 2020 14:19:23 -0400 Subject: [tz] Proper (stable) way to list installed time zones? Message-ID: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> As part of the implementation of IANA time zone support in the Python standard library (which is now accepted for inclusion in Python 3.9 ? many thanks to those who commented on the original proposal), I realized that likely a common feature request is to get the list of time zones installed in the system. I have a candidate implementation for this, which basically walks each potential install directory (there's a "time zone search path" equivalent to PATH) and populates a list of every file installed there which starts with the `TZif` magic string. The problem I'm running into is that tzcode installs `posix/` and `right/` folders, so for each entry in zoneinfo, I get three entries: "Africa/Abidjan", "posix/Africa/Abidjan" and "right/Africa/Abidjan". I'm also seeing a `posixrules` zone in the zoneinfo root. My questions are: 1. Is there a better source for the list of installed time zones (leaving aside `tzdata.zi`, which I don't think I can count on to exist in all environments). 2. Is there any stable and standard way to distinguish between proper zones and other things that are also zone files like posixrules and right/ and posix/? In my own redistribution of the data, I populate a list of zones from `make zonenames`, which I note does /not/ include posix/, right/ or posixrules, but I don't think that information is included in standard distributions of zoneinfo. The closest I can find is `zone1970.tab` and `zone.tab` (which I think is not even always included), and that appears to be only a subset of the output of `make zonenames`. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tim at timtimeonline.com Thu May 14 01:54:57 2020 From: tim at timtimeonline.com (Tim Parenti) Date: Wed, 13 May 2020 21:54:57 -0400 Subject: [tz] Removing systemv, pacificnew, Rule TYPEs, zic -y Message-ID: I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references. Of course, I was only looking at systemv in the first place because I'd also recalled that we're still distributing the pacificnew file, which has caused some confusion every so often and has likewise generally outlived its usefulness. This led me to the related file yearistype.sh, which is also unused, except as a default script to pass to the Makefile to process the TYPE field of Rule lines. Given that the TYPE field hasn't been used by tzdata since 2000f and has been more formally deprecated since 2015f, the whole unused feature is ripe for "spring cleaning". The attached proposed patch 0002 completely drops support for the TYPE field (marking it reserved for compatibility purposes) and causes non-trivial use of the field or use of zic's -y option to error (instead of warning as it has since 2017c). It also removes the pacificnew and yearistype.sh files that are no longer needed and updates documentation accordingly. I don't presently foresee any need to repurpose the nullified field down the road, but this is the next step in allowing us to "reclaim" it in the event that such a need should arise in the future. -- Tim Parenti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-obsolete-file-systemv.patch Type: application/octet-stream Size: 4344 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Drop-support-for-zic-y-Rule-TYPEs-pacificnew.patch Type: application/octet-stream Size: 75235 bytes Desc: not available URL: From eggert at cs.ucla.edu Thu May 14 02:13:37 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Wed, 13 May 2020 19:13:37 -0700 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> Message-ID: <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> On 5/13/20 11:19 AM, Paul Ganssle wrote: > The problem I'm running into is that tzcode installs `posix/` and > `right/` folders, so for each entry in zoneinfo, I get three entries: > "Africa/Abidjan", "posix/Africa/Abidjan" and "right/Africa/Abidjan". I'm > also seeing a `posixrules` zone in the zoneinfo root. The posix/* entries are duplicates are the main ones, and the right/* entries are with leap seconds (which aren't normally used). The posixrules is for when one uses a nonconforming TZ string like TZ='EST5EDT'. > 1. Is there a better source for the list of installed time zones > (leaving aside `tzdata.zi`, which I don't think I can count on to exist > in all environments). That depends on what you want the list for. If you want every value V such that TZ='V' works via reading files, you've got the right list. If you want every value V such that TZ='V' works, then you have just a subset since POSIX-style Vs are not taken from files. If you want a shorter list (which makes sense), you can omit the posix/* and right/* and posixrules entries. > 2. Is there any stable and standard way to distinguish between proper > zones and other things that are also zone files like posixrules and > right/ and posix/? Depends on what you mean by 'proper'. :-) 'make zonenames' should be equivalent to looking in tzdata.zi, because that's what 'make zonenames' does. And that should be equivalent to the "shorter list" mentioned above. > The closest I can find is `zone1970.tab` and > `zone.tab` (which I think is not even always included), and that appears > to be only a subset of the output of `make zonenames`. Yup. The method I'd suggest is tzdata.zi if available, or the "shorter list" mentioned above, whichever's faster. This is because zone1970.tab and zone.tab don't list some of the duplicates, and some users like the duplicates. If you also want the leap-second entries, you'll need the right/* entries though. From paul at ganssle.io Fri May 15 14:39:04 2020 From: paul at ganssle.io (Paul Ganssle) Date: Fri, 15 May 2020 10:39:04 -0400 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> Message-ID: This is very tough, because there are a lot of plausible subsets that someone could want, and there are not good names for them all (nor, it seems, do they all have a foolproof method of detection). I'd say one could easily want: 1. Every valid value for key that doesn't raise an error when you call ZoneInfo(key) 2. All the values found in tzdata.zi 3. The intersection of the values found in tzdata.zi and the keys that actually exist on disk 4. All the values from zone.tab and/or zone1970.tab 5. The intersection of #4 and all the keys that actually exist on disk 6. #4 or #5, but also including "UTC" (and possibly the fixed-offset zones like Etc/GMT+5 or whatever) My inclination would be to compile a list of zones annotated with each entry's membership in each of these groups and let the end user filter as desired, but that's slightly complicated by the fact that almost all the indicators other than #1 may be manipulated by the install mechanism, and it becomes hard to distinguish between "not present in tzdata.zi" and "tzdata.zi not shipped". That said, it sounds to me like we can probably safely say that it is unlikely that we won't have to special case any names of folders or files /other/ than posixrules, posix/ and right/ for the foreseeable future and that if distros rename those files but still put them under the zoneinfo root, that's probably safely considered a bug in the distro. I'm still mildly uncertain as to whether it's possible that tzdata.zi might have more zones than are actually installed (for example if a distro doesn't install anything in backward or antarctica for some reason). With regards to this: > If you also want the leap-second entries, you'll need the right/* entries though. Is it always the case that the right/ and posix/ trees are identical to the primary tree? If so, it's reasonable to leave right/ and posix/ out of the listings and users can know that if they want the right/* entries, they can just prepend "right/" to any given key. Best, Paul On 5/15/20 9:43 AM, Filipe La?ns wrote: > On Wed, 2020-05-13 at 19:13 -0700, Paul Eggert wrote: >> Yup. The method I'd suggest is tzdata.zi if available, or the "shorter list" >> mentioned above, whichever's faster. This is because zone1970.tab and zone.tab >> don't list some of the duplicates, and some users like the duplicates. >> >> If you also want the leap-second entries, you'll need the right/* entries though. > I am thinking the best approach should be reading tzdata.zi when > available, and potentially fallback to ignoring posix/* and > right/* and posixrules. I am not sure about this last one though, for > reasons outlined in the PR. What do you think Paul (G.)? > > Filipe La?ns -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From eggert at cs.ucla.edu Fri May 15 19:52:35 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 15 May 2020 12:52:35 -0700 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> Message-ID: <2f73c604-0592-224b-7f57-f065617faa87@cs.ucla.edu> On 5/15/20 7:39 AM, Paul Ganssle wrote: > I'd say one > could easily want: > > 1. Every valid value for key that doesn't raise an error when you call > ZoneInfo(key) Does ZoneInfo operate by looking for an actual file, or by setting TZ='key' and seeing whether that works? If the latter, there are many keys that are not listed anywhere because they're specified by POSIX. A simple example is TZ='MST7' which is a valid POSIX key and which is commonly used, but for which there is no file or tzdata.zi entry. I looked at PEP 615 and didn't see any mention of the issue of POSIX-specified TZ settings. > I'm still mildly uncertain as to whether it's possible that tzdata.zi > might have more zones than are actually installed (for example if a > distro doesn't install anything in backward or antarctica for some reason). In the reference implementation, the zones are installed from tzdata.zi so the lists should be identical there. > Is it always the case that the right/ and posix/ trees are identical to > the primary tree? Yes, in the reference implementation. From lains at archlinux.org Fri May 15 13:43:05 2020 From: lains at archlinux.org (Filipe =?ISO-8859-1?Q?La=EDns?=) Date: Fri, 15 May 2020 14:43:05 +0100 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> Message-ID: On Wed, 2020-05-13 at 19:13 -0700, Paul Eggert wrote: > Yup. The method I'd suggest is tzdata.zi if available, or the "shorter list" > mentioned above, whichever's faster. This is because zone1970.tab and zone.tab > don't list some of the duplicates, and some users like the duplicates. > > If you also want the leap-second entries, you'll need the right/* entries though. I am thinking the best approach should be reading tzdata.zi when available, and potentially fallback to ignoring posix/* and right/* and posixrules. I am not sure about this last one though, for reasons outlined in the PR. What do you think Paul (G.)? Filipe La?ns -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From Brian.Inglis at SystematicSw.ab.ca Fri May 15 22:25:25 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Fri, 15 May 2020 16:25:25 -0600 Subject: [tz] Proper (stable) way to list installed time zones? In-Reply-To: <2f73c604-0592-224b-7f57-f065617faa87@cs.ucla.edu> References: <7b36d1d3-35f0-5396-d145-86bf60b1feff@ganssle.io> <18a6f66c-d1a2-9baa-eec3-4c0b010024a3@cs.ucla.edu> <2f73c604-0592-224b-7f57-f065617faa87@cs.ucla.edu> Message-ID: <90c5c29c-9cf8-46ec-1006-d6251ffcd773@SystematicSw.ab.ca> On 2020-05-15 13:52, Paul Eggert wrote: > On 5/15/20 7:39 AM, Paul Ganssle wrote: >> I'd say one >> could easily want: >> >> 1. Every valid value for key that doesn't raise an error when you call >> ZoneInfo(key) > > Does ZoneInfo operate by looking for an actual file, or by setting TZ='key' and > seeing whether that works? If the latter, there are many keys that are not > listed anywhere because they're specified by POSIX. A simple example is > TZ='MST7' which is a valid POSIX key and which is commonly used, but for which > there is no file or tzdata.zi entry. I looked at PEP 615 and didn't see any > mention of the issue of POSIX-specified TZ settings. > >> I'm still mildly uncertain as to whether it's possible that tzdata.zi >> might have more zones than are actually installed (for example if a >> distro doesn't install anything in backward or antarctica for some reason). > > In the reference implementation, the zones are installed from tzdata.zi so the > lists should be identical there. > >> Is it always the case that the right/ and posix/ trees are identical to >> the primary tree? > > Yes, in the reference implementation. For every zone in the sources, try the following from your tzdata directory: $ awk ' /^Zone/ { print $2, "Zone", FILENAME } /^Link/ { print $3, "Link", FILENAME, $2 } /^[^#]/ && FILENAME ~ /zone[^.]*\.tab/ { print $3, "Tab", FILENAME, $1, $2 } ' africa antarctica asia australasia backward backzone etcetera \ europe factory northamerica pacificnew solar8[7-9] systemv \ usno1988 usno1989 usno1989a usno199[578] zone.tab zone1970.tab | \ sort -dfuk1,1 you can drop the sort -u or the sort command to see the selected data, or drop the extra fields to just get the zone names - 586 unique entries total possible. If I missed some selection source or criterion please post on the list. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From tim at timtimeonline.com Sun May 17 17:55:16 2020 From: tim at timtimeonline.com (Tim Parenti) Date: Sun, 17 May 2020 13:55:16 -0400 Subject: [tz] Updating zic.c to further match Link line field names Message-ID: In working on my latest proposed patch, I also noticed an outdated error message in zic.c which referred to the FROM field of a Link line. We had updated these field names in comments and documentation in release 2014g to be more descriptive and readily understandable like the parameters of 'ln': https://github.com/eggert/tz/commit/78e3924ea43079a0f3333677a728e0f0ed679cd3 The attached proposed patch further updates the zic.c code to more consistently use these new names throughout. This mostly affects the naming of parameters and locals, but a few macros and struct fields are also updated for consistency. -- Tim Parenti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Further-update-code-to-match-Link-line-field-names.patch Type: application/octet-stream Size: 8822 bytes Desc: not available URL: From gkssarma59 at gmail.com Wed May 20 11:32:25 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Wed, 20 May 2020 17:02:25 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: Message-ID: Hello team, According to the latest 2020a tz update: Canada's Yukon, represented by America/Whitehorse and America/Dawson, advanced to -07 year-round, beginning with its spring-forward transition on 2020-03-08, and will not fall back on 2020-11-01. We have written a test cases like below for canada yukon timezone. We imported new 2020a tz into our environment. Our code seems correct but test cases are failing. So we found that there is wrong in Iana tz side. Please check and correct us. This is the below code we have written. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on 2nd nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); -------> here we are getting error: java.lang.AssertionError: expected:<-7> but was:<-8> } The above test case according to your update (will not fall back on 2020-11-01) is correct. But test case is failing. Could you please clarify us that is there anything wrong from IANA tz. If not how can i write my test case according to that? Regards, Sundar On Wed, May 20, 2020 at 3:51 PM wrote: > Welcome to the tz at iana.org mailing list! > > > --- > > NOTE WELL > > Any submission to the IETF intended by the Contributor for publication > as all or part of an IETF Internet-Draft or RFC and any statement made > within the context of an IETF activity is considered an "IETF > Contribution". Such statements include oral statements in IETF > sessions, as well as written and electronic communications made at any > time or place, which are addressed to: > > * The IETF plenary session * The IESG, or any member thereof on behalf > of the IESG * Any IETF mailing list, including the IETF list itself, > any working group or design team list, or any other list functioning > under IETF auspices * Any IETF working group or portion thereof * Any > Birds of a Feather (BOF) session * The IAB or any member thereof on > behalf of the IAB * The RFC Editor or the Internet-Drafts function * > All IETF Contributions are subject to the rules of RFC 5378 and RFC > 3979 (updated by RFC 4879). > > Statements made outside of an IETF session, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not IETF Contributions in the context > of this notice. > > Please consult RFC 5378 and RFC 3979 for details. > > A participant in any IETF activity is deemed to accept all IETF rules > of process, as documented in Best Current Practices RFCs and IESG > Statements. > > A participant in any IETF activity acknowledges that written, audio > and video records of meetings may be made and may be available to the > public. > > --- > > To post to this list, send your email to: > > tz at iana.org > > General information about the mailing list is at: > > https://mm.icann.org/mailman/listinfo/tz > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://mm.icann.org/mailman/options/tz/gkssarma59%40gmail.com > > You can also make such adjustments via email by sending a message to: > > tz-request at iana.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > Gks59 at smu > > Normally, Mailman will remind you of your iana.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Wed May 20 15:17:29 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Wed, 20 May 2020 09:17:29 -0600 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: Message-ID: <674f650a-6b98-0e28-8b60-464a45639cdf@SystematicSw.ab.ca> On 2020-05-20 05:32, Sundar Sarma wrote: > According to the latest 2020a tz update: Canada's Yukon, represented by > America/Whitehorse and > ? ? America/Dawson, advanced to -07 year-round, beginning with its > ? ? spring-forward transition on 2020-03-08, and will not fall back on > ? ? 2020-11-01. > We have written a test cases like below for canada yukon timezone. We imported > new 2020a tz into our environment. > Our code seems correct but test cases are failing. So we found that there is > wrong in Iana tz side. > Please check and correct us. This is the below code we have written. > @Test > ? ? public void doesNotFallBackToMinus8InDawsonNovember2020() { > ? ? ? ? DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); > ? ? ? ? Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on > 2nd nov 00:00:00 > ? ? ? ? ? ? ? ? .withLaterOffsetAtOverlap() > ? ? ? ? ? ? ? ? .toInstant(); > ? ? ? ? Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st > nov 00:00:00 > ? ? ? ? ? ? ? ? .withLaterOffsetAtOverlap() > ? ? ? ? ? ? ? ? .toInstant(); > ? ? ? ? long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); > ? ? ? ? int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); > ? ? ? ? long offsetOnDay = timezone.getOffset(day.getMillis()); > ? ? ? ? int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); > ? ? ? ? assertEquals(hoursOnDay, dayAfterHours); ?-------> ?here we are getting > error: java.lang.AssertionError: expected:<-7> but was:<-8> > ? ? } > The above test case according to your update (will not fall back on 2020-11-01) > is correct. But test case is failing. > Could you please clarify us that is there anything wrong from IANA tz. > If not how can i write my test case according to that?? For a start, you must always take account of the summer transition times forward and back. Across Canada, times change at Sunday 02:00 local time: in March, as each time zone hits 02:00, it becomes 03:00; in November, as each time zone hits 02:00, it becomes 01:00: $ zdump -Vc2020,2021 Canada/Mountain | sed 's/\(Sun\).*\1/\1/' Canada/Mountain Sun Mar 8 01:59:59 2020 MST isdst=0 gmtoff=-25200 Canada/Mountain Sun Mar 8 03:00:00 2020 MDT isdst=1 gmtoff=-21600 Canada/Mountain Sun Nov 1 01:59:59 2020 MDT isdst=1 gmtoff=-21600 Canada/Mountain Sun Nov 1 01:00:00 2020 MST isdst=0 gmtoff=-25200 so to be sure, you need to check on or after each transition, as you will have ambiguous times on Sunday in March between 01:00 and 02:00, and in November between 02:00 and 03:00. In both cases, you could check on or after Sun 03:00. Checking at 12:00 noon is often chosen to be safe regardless of actual transition times, which could vary from 00:00 to 06:00. Similarly, checks are often done on December 31 and June 30 to avoid being near any northern or southern hemisphere transition dates. However in recent years Islamic countries have started to reset summer time changes during Ramadan, which can occur any time in the Gregorian calendar. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From gkssarma59 at gmail.com Wed May 20 16:55:12 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Wed, 20 May 2020 22:25:12 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <674f650a-6b98-0e28-8b60-464a45639cdf@SystematicSw.ab.ca> References: <674f650a-6b98-0e28-8b60-464a45639cdf@SystematicSw.ab.ca> Message-ID: Is Yukon part of Canada/Mountain? Regards, Sundar On Wed, May 20, 2020 at 8:47 PM Brian Inglis < Brian.Inglis at systematicsw.ab.ca> wrote: > On 2020-05-20 05:32, Sundar Sarma wrote: > > According to the latest 2020a tz update: Canada's Yukon, represented by > > America/Whitehorse and > > America/Dawson, advanced to -07 year-round, beginning with its > > spring-forward transition on 2020-03-08, and will not fall back on > > 2020-11-01. > > We have written a test cases like below for canada yukon timezone. We > imported > > new 2020a tz into our environment. > > Our code seems correct but test cases are failing. So we found that > there is > > wrong in Iana tz side. > > Please check and correct us. This is the below code we have written. > > @Test > > public void doesNotFallBackToMinus8InDawsonNovember2020() { > > DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); > > Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, > timezone)-------> on > > 2nd nov 00:00:00 > > .withLaterOffsetAtOverlap() > > .toInstant(); > > Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> > on 1 st > > nov 00:00:00 > > .withLaterOffsetAtOverlap() > > .toInstant(); > > long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); > > int dayAfterHours = (int) > TimeUnit.MILLISECONDS.toHours(dayAfterOffset); > > long offsetOnDay = timezone.getOffset(day.getMillis()); > > int hoursOnDay = (int) > TimeUnit.MILLISECONDS.toHours(offsetOnDay); > > assertEquals(hoursOnDay, dayAfterHours); -------> here we are > getting > > error: java.lang.AssertionError: expected:<-7> but was:<-8> > > } > > The above test case according to your update (will not fall back on > 2020-11-01) > > is correct. But test case is failing. > > Could you please clarify us that is there anything wrong from IANA tz. > > If not how can i write my test case according to that? > > For a start, you must always take account of the summer transition times > forward > and back. > Across Canada, times change at Sunday 02:00 local time: in March, as each > time > zone hits 02:00, it becomes 03:00; in November, as each time zone hits > 02:00, it > becomes 01:00: > > $ zdump -Vc2020,2021 Canada/Mountain | sed 's/\(Sun\).*\1/\1/' > Canada/Mountain Sun Mar 8 01:59:59 2020 MST isdst=0 gmtoff=-25200 > Canada/Mountain Sun Mar 8 03:00:00 2020 MDT isdst=1 gmtoff=-21600 > Canada/Mountain Sun Nov 1 01:59:59 2020 MDT isdst=1 gmtoff=-21600 > Canada/Mountain Sun Nov 1 01:00:00 2020 MST isdst=0 gmtoff=-25200 > > so to be sure, you need to check on or after each transition, as you will > have > ambiguous times on Sunday in March between 01:00 and 02:00, and in November > between 02:00 and 03:00. > In both cases, you could check on or after Sun 03:00. > Checking at 12:00 noon is often chosen to be safe regardless of actual > transition times, which could vary from 00:00 to 06:00. > Similarly, checks are often done on December 31 and June 30 to avoid being > near > any northern or southern hemisphere transition dates. > However in recent years Islamic countries have started to reset summer time > changes during Ramadan, which can occur any time in the Gregorian calendar. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at timtimeonline.com Wed May 20 19:22:05 2020 From: tim at timtimeonline.com (Tim Parenti) Date: Wed, 20 May 2020 15:22:05 -0400 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: <674f650a-6b98-0e28-8b60-464a45639cdf@SystematicSw.ab.ca> Message-ID: On Wed, 20 May 2020 at 12:55, Sundar Sarma wrote: > Is Yukon part of Canada/Mountain? > No; Canada/Mountain is a link in the 'backward' file to America/Edmonton which is only present for backwards compatibility and should generally not be used. Splits and differences like this underline the importance of using the correct and supported identifiers wherever possible. -- Tim Parenti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eggert at cs.ucla.edu Wed May 20 22:01:32 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Wed, 20 May 2020 15:01:32 -0700 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: Message-ID: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> On 5/20/20 4:32 AM, Sundar Sarma wrote: > The above test case according to your update (will not fall back on > 2020-11-01) is correct. But test case is failing. My guess is that you didn't propagate the data into Java. Java doesn't use tzdata's TZif files directly; it builds and installs its own copy of the files and uses that. If Java's copy is obsolete then Java programs will report obsolete results. For more about this see and look for "Oracle Java". You can test this by running the shell command: zdump -v -c 2020,2021 America/Dawson If older tzdata is installed you'll see this: $ zdump -v -c 2020,2022 America/Dawson America/Dawson -9223372036854775808 = NULL America/Dawson -9223372036854689408 = NULL America/Dawson Sun Mar 8 09:59:59 2020 UTC = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UTC = Sun Mar 8 03:00:00 2020 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 1 08:59:59 2020 UTC = Sun Nov 1 01:59:59 2020 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 1 09:00:00 2020 UTC = Sun Nov 1 01:00:00 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 14 09:59:59 2021 UTC = Sun Mar 14 01:59:59 2021 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 14 10:00:00 2021 UTC = Sun Mar 14 03:00:00 2021 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 7 08:59:59 2021 UTC = Sun Nov 7 01:59:59 2021 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 7 09:00:00 2021 UTC = Sun Nov 7 01:00:00 2021 PST isdst=0 gmtoff=-28800 America/Dawson 9223372036854689407 = NULL America/Dawson 9223372036854775807 = NULL with transitions continuing this fall and next year. In tzdata 2020a you'll see this: $ zdump -v -c 2020,2022 America/Dawson America/Dawson -9223372036854775808 = NULL America/Dawson -9223372036854689408 = NULL America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 MST isdst=0 gmtoff=-25200 America/Dawson 9223372036854689407 = NULL America/Dawson 9223372036854775807 = NULL with transitions stopping after March of this year, and Yukon observing MST now. If you see the latter output then your tzdata is up-to-date; if Java is reporting incorrect results in this area then the problem has something to do with the Java installation, which is downstream from us. From eggert at cs.ucla.edu Wed May 20 22:03:45 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Wed, 20 May 2020 15:03:45 -0700 Subject: [tz] Tim Parenti as backup TZ Coordinator? Message-ID: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Tim Parenti's recent emails to the list reminded me that I'd long been meaning to nominate him to be my backup as TZ Coordinator. We should have a backup in case I am no longer available due to retirement or whatever, not that I'm planning to retire any time soon. I would like to start by giving him commit privileges to the development repository on GitHub, so that his contributions can become part of releases more easily. Tim has been a longtime and substantial contributor to tzdb, as evidenced by his detailed and careful patches. Although he's mostly worked in the tzdata area, he's also proficient on the code side, as his recent patch proposals demonstrate. He and I have corresponded by email about this and he's indicated his willingness to take on the responsibility. I'd appreciate reactions to Tim's offer to be backup; please respond within the next week. From Brian.Inglis at SystematicSw.ab.ca Wed May 20 22:17:24 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Wed, 20 May 2020 16:17:24 -0600 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <7b854b3f-66cd-2200-9cfb-52bcd3ccf2ac@SystematicSw.ab.ca> On 2020-05-20 16:03, Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. > I would like to start by giving him commit privileges to the development > repository on GitHub, so that his contributions can become part of releases > more easily. > I'd appreciate reactions to Tim's offer to be backup; please respond within > the next week. ++ From murch at fastmail.com Wed May 20 22:20:02 2020 From: murch at fastmail.com (Ken Murchison) Date: Wed, 20 May 2020 18:20:02 -0400 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: +1 On 5/20/20 6:03 PM, Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. We should > have a backup in case I am no longer available due to retirement or > whatever, not that I'm planning to retire any time soon. I would like > to start by giving him commit privileges to the development repository > on GitHub, so that his contributions can become part of releases more > easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as > his recent patch proposals demonstrate. He and I have corresponded by > email about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From philip at trouble.is Thu May 21 06:03:08 2020 From: philip at trouble.is (Philip Paeps) Date: Thu, 21 May 2020 14:03:08 +0800 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <6EC83656-FA82-40DB-977C-E124FA94E4A8@trouble.is> On 2020-05-21 06:03:45 (+0800), Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. We should > have a backup in case I am no longer available due to retirement or > whatever, not that I'm planning to retire any time soon. I would like > to start by giving him commit privileges to the development repository > on GitHub, so that his contributions can become part of releases more > easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as > his recent patch proposals demonstrate. He and I have corresponded by > email about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. +1 Great idea. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From alanp at snowmoose.com Thu May 21 06:09:44 2020 From: alanp at snowmoose.com (Alan Perry) Date: Wed, 20 May 2020 23:09:44 -0700 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: On 5/20/20 3:03 PM, Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. We should > have a backup in case I am no longer available due to retirement or > whatever, not that I'm planning to retire any time soon. I would like > to start by giving him commit privileges to the development repository > on GitHub, so that his contributions can become part of releases more > easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as > his recent patch proposals demonstrate. He and I have corresponded by > email about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. I haven't actually worked with tzcode or tzdata in over 15 years, but it is a topic that still interests me, so I am still here. If my opinion counts for anything, +1 alan From guy at alum.mit.edu Thu May 21 06:53:15 2020 From: guy at alum.mit.edu (Guy Harris) Date: Wed, 20 May 2020 23:53:15 -0700 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <54DA9284-9CCE-481A-A120-31F0DA36CA68@alum.mit.edu> On May 20, 2020, at 3:03 PM, Paul Eggert wrote: > I'd appreciate reactions to Tim's offer to be backup +1 From clive at davros.org Thu May 21 06:33:27 2020 From: clive at davros.org (Clive D.W. Feather) Date: Thu, 21 May 2020 07:33:27 +0100 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <20200521063327.GB31931@davros.org> Paul Eggert said: > I'd appreciate > reactions to Tim's offer to be backup; please respond within the next week. I don't have any specific opinions about Tim, but succession planning is a good idea and I'm glad to see it's happening here. -- Clive D.W. Feather | If you lie to the compiler, Email: clive at davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 From gkssarma59 at gmail.com Thu May 21 12:39:33 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Thu, 21 May 2020 18:09:33 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> Message-ID: Finally, could you please confirm that is there anything wrong in my code? Still i did not understand why this test case is failing with new 2020a tz. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone) .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone) .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); } On Thu, May 21, 2020 at 3:31 AM Paul Eggert wrote: > On 5/20/20 4:32 AM, Sundar Sarma wrote: > > The above test case according to your update (will not fall back on > > 2020-11-01) is correct. But test case is failing. > > My guess is that you didn't propagate the data into Java. Java doesn't > use tzdata's TZif files directly; it builds and installs its own copy of > the files and uses that. If Java's copy is obsolete then Java programs > will report obsolete results. For more about this see > and look for "Oracle > Java". > > You can test this by running the shell command: > > zdump -v -c 2020,2021 America/Dawson > > If older tzdata is installed you'll see this: > > $ zdump -v -c 2020,2022 America/Dawson > America/Dawson -9223372036854775808 = NULL > America/Dawson -9223372036854689408 = NULL > America/Dawson Sun Mar 8 09:59:59 2020 UTC = Sun Mar 8 01:59:59 2020 > PST isdst=0 gmtoff=-28800 > America/Dawson Sun Mar 8 10:00:00 2020 UTC = Sun Mar 8 03:00:00 2020 > PDT isdst=1 gmtoff=-25200 > America/Dawson Sun Nov 1 08:59:59 2020 UTC = Sun Nov 1 01:59:59 2020 > PDT isdst=1 gmtoff=-25200 > America/Dawson Sun Nov 1 09:00:00 2020 UTC = Sun Nov 1 01:00:00 2020 > PST isdst=0 gmtoff=-28800 > America/Dawson Sun Mar 14 09:59:59 2021 UTC = Sun Mar 14 01:59:59 2021 > PST isdst=0 gmtoff=-28800 > America/Dawson Sun Mar 14 10:00:00 2021 UTC = Sun Mar 14 03:00:00 2021 > PDT isdst=1 gmtoff=-25200 > America/Dawson Sun Nov 7 08:59:59 2021 UTC = Sun Nov 7 01:59:59 2021 > PDT isdst=1 gmtoff=-25200 > America/Dawson Sun Nov 7 09:00:00 2021 UTC = Sun Nov 7 01:00:00 2021 > PST isdst=0 gmtoff=-28800 > America/Dawson 9223372036854689407 = NULL > America/Dawson 9223372036854775807 = NULL > > with transitions continuing this fall and next year. In tzdata 2020a > you'll see this: > > $ zdump -v -c 2020,2022 America/Dawson > America/Dawson -9223372036854775808 = NULL > America/Dawson -9223372036854689408 = NULL > America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 > PST isdst=0 gmtoff=-28800 > America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 > MST isdst=0 gmtoff=-25200 > America/Dawson 9223372036854689407 = NULL > America/Dawson 9223372036854775807 = NULL > > with transitions stopping after March of this year, and Yukon observing > MST now. If you see the latter output then your tzdata is up-to-date; if > Java is reporting incorrect results in this area then the problem has > something to do with the Java installation, which is downstream from us. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.h.deckers at googlemail.com Thu May 21 13:09:47 2020 From: michael.h.deckers at googlemail.com (Michael H Deckers) Date: Thu, 21 May 2020 13:09:47 +0000 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> Message-ID: <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> ?? On 2020-05-21 12:39, Sundar Sarma wrote: > Still i did not understand why this test case is failing with new 2020a tz. ?? The version of the IANA database installed in the operating ?? system may well differ from the version used by Java.time. ?? The latter can be determined with the method ??????? ZoneRulesProvider.getVersions?( String zoneId ). ?? which gives the version used by Java. ?? HTH. ?? Michael Deckers. From patsy at redhat.com Thu May 21 13:28:15 2020 From: patsy at redhat.com (Patsy Griffin) Date: Thu, 21 May 2020 09:28:15 -0400 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: +1 On Wed, May 20, 2020 at 6:04 PM Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long been > meaning to nominate him to be my backup as TZ Coordinator. We should > have a backup in case I am no longer available due to retirement or > whatever, not that I'm planning to retire any time soon. I would like to > start by giving him commit privileges to the development repository on > GitHub, so that his contributions can become part of releases more easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as his > recent patch proposals demonstrate. He and I have corresponded by email > about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at whooppee.com Thu May 21 13:59:39 2020 From: paul at whooppee.com (Paul Goyette) Date: Thu, 21 May 2020 06:59:39 -0700 (PDT) Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: On Wed, May 20, 2020 at 6:04 PM Paul Eggert wrote: > Tim Parenti's recent emails to the list reminded me that I'd long > been meaning to nominate him to be my backup as TZ Coordinator. We > should have a backup in case I am no longer available due to > retirement or whatever, not that I'm planning to retire any time soon. > I would like to start by giving him commit privileges to the > development repository on GitHub, so that his contributions can become > part of releases more easily. > > Tim has been a longtime and substantial contributor to tzdb, as > evidenced by his detailed and careful patches. Although he's mostly > worked in the tzdata area, he's also proficient on the code side, as > his recent patch proposals demonstrate. He and I have corresponded by > email about this and he's indicated his willingness to take on the > responsibility. I'd appreciate reactions to Tim's offer to be backup; > please respond within the next week. Another +1 from me, FWIW. +--------------------+--------------------------+-----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--------------------+--------------------------+-----------------------+ From gkssarma59 at gmail.com Thu May 21 15:06:04 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Thu, 21 May 2020 20:36:04 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: after i run this code ZoneRulesProvider.getVersions( String zoneId ). i got below output {2016a=ZoneRules[currentStandardOffset=-08:00]} But in readme file of tzadata, Generated by Gradle I am getting below verison. Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz On Thu, May 21, 2020 at 6:39 PM Michael H Deckers < michael.h.deckers at googlemail.com> wrote: > > On 2020-05-21 12:39, Sundar Sarma wrote: > > > > Still i did not understand why this test case is failing with new 2020a > tz. > > > The version of the IANA database installed in the operating > system may well differ from the version used by Java.time. > The latter can be determined with the method > ZoneRulesProvider.getVersions?( String zoneId ). > which gives the version used by Java. > > HTH. > > Michael Deckers. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Thu May 21 16:18:41 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Thu, 21 May 2020 10:18:41 -0600 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: <6764db79-3f34-f3ab-5ae6-768714b2e1a3@SystematicSw.ab.ca> On 2020-05-21 07:09, Michael H Deckers via tz wrote: > > ?? On 2020-05-21 12:39, Sundar Sarma wrote: > > >> Still i did not understand why this test case is failing with new 2020a tz. > > > ?? The version of the IANA database installed in the operating > ?? system may well differ from the version used by Java.time. > ?? The latter can be determined with the method > ??????? ZoneRulesProvider.getVersions?( String zoneId ). > ?? which gives the version used by Java. >From Google and SO, with recent versions, you can do: $ jshell <<< \ 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' | Welcome to JShell -- Version 11.0.7 | For an introduction type: /help intro jshell> System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); [2019c] jshell> $ *OR* $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat /usr/lib/jvm/java-1.11.0-openjdk-i386/lib/tzdb.dat:TZDB2019c /usr/lib/jvm/java-11-openjdk-i386/lib/tzdb.dat:TZDB2019c what is actually matched is: $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat | cat -A /usr/lib/jvm/java-1.11.0-openjdk-i386/lib/tzdb.dat:^A^@^DTZDB^@^A^@^E2019c$ /usr/lib/jvm/java-11-openjdk-i386/lib/tzdb.dat:^A^@^DTZDB^@^A^@^E2019c$ so there's a code and a byte count and some zeros or nulls, so you could dump just those: $ for dat in /usr/lib/jvm/*/lib/tzdb.dat do echo $dat: head -n1 $dat | cut -c12-16 done /usr/lib/jvm/java-1.11.0-openjdk-i386/lib/tzdb.dat: 2019c /usr/lib/jvm/java-11-openjdk-i386/lib/tzdb.dat: 2019c *OR* equivalents on other systems e.g. for Oracle it should be something like: $ grep -ao '^javazm.....tzdata[12][90][0-9][0-9][a-z]' \ $JAVA_HOME/jre/lib/zi/ZoneInfoMappings *OR* $ head -n1 $JAVA_HOME/jre/lib/zi/ZoneInfoMappings | cut -c18-22 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From eggert at cs.ucla.edu Thu May 21 20:33:41 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 21 May 2020 13:33:41 -0700 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <6764db79-3f34-f3ab-5ae6-768714b2e1a3@SystematicSw.ab.ca> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <6764db79-3f34-f3ab-5ae6-768714b2e1a3@SystematicSw.ab.ca> Message-ID: <1e8676f6-5d3a-461c-21f5-f43bb60f166d@cs.ucla.edu> On 5/21/20 9:18 AM, Brian Inglis wrote: > System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); > [2019c] Thanks for that jshell recipe. I observe the same "2019c" on my Ubuntu 18.04.4 laptop, even though Ubuntu 18.04.4 has updated tzdata to 2020a, as can be seen from this shell command: $ zdump -V -c 2020,2021 America/Dawson America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 MST isdst=0 gmtoff=-25200 So I am observing the same symptoms that Sundar Sarma reports: my tzdata package is up-to-date but its Java copy is not. There are recipes for fixing the problem by updating the Java copy. For Oracle Java, see . For OpenJDK or some other Java, you can try ZIUpdater , tzdbgen , and/or IANA Updater . I'm not going to bother to run any of those since I don't normally run Java apps on my laptop. This Java stuff is all downstream from the tz project proper, so those who have problems with it should contact whoever's maintaining the Java software they're using. From Brian.Inglis at SystematicSw.ab.ca Thu May 21 21:42:00 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Thu, 21 May 2020 15:42:00 -0600 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: <1e8676f6-5d3a-461c-21f5-f43bb60f166d@cs.ucla.edu> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <6764db79-3f34-f3ab-5ae6-768714b2e1a3@SystematicSw.ab.ca> <1e8676f6-5d3a-461c-21f5-f43bb60f166d@cs.ucla.edu> Message-ID: On 2020-05-21 14:33, Paul Eggert wrote: > On 5/21/20 9:18 AM, Brian Inglis wrote: > >> System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); >> [2019c] > > Thanks for that jshell recipe. I observe the same "2019c" on my Ubuntu 18.04.4 > laptop, even though Ubuntu 18.04.4 has updated tzdata to 2020a, as can be seen > from this shell command: > > $ zdump -V -c 2020,2021 America/Dawson > America/Dawson? Sun Mar? 8 09:59:59 2020 UT = Sun Mar? 8 01:59:59 2020 PST > isdst=0 gmtoff=-28800 > America/Dawson? Sun Mar? 8 10:00:00 2020 UT = Sun Mar? 8 03:00:00 2020 MST > isdst=0 gmtoff=-25200 > > So I am observing the same symptoms that Sundar Sarma reports: my tzdata package > is up-to-date but its Java copy is not. > > There are recipes for fixing the problem by updating the Java copy. > For Oracle Java, see > . > For OpenJDK or some other Java, you can try ZIUpdater > , > tzdbgen , > and/or IANA Updater . > I'm not going to bother to run any of those since I don't normally run Java > apps on my laptop. > > This Java stuff is all downstream from the tz project proper, so those who have > problems with it should contact whoever's maintaining the Java software they're > using. There should be coordination within each distro about triggering the local Java package TZ updater when the system tzdata is updated. My weekly cron tzdata release check script would run the TZ Updater against the new release if I still had Java and its TZ Updater installed: it's not hard. Perhaps those with wide deployments of distros with Java packages and apps could submit bug reports against their distro Java packages to apply TZ updates when tzdata packages are updated. Perhaps vendor JVM providers could sponsor packaging their JVM, TZ Updaters, and applying TZ updates when system tzdata is updated on distros they support using, rather than leaving it to system or app support or users. I haven't searched, but apparently even MS Windows now includes tzdata to support their MS Windows store apps or its infrastructure, and must update that, along with their proprietary Windows TZ updates. JVM providers could help more to keep their tzdata up to date, and that could and should be seen as a competitive advantage. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From john.haxby at oracle.com Fri May 22 09:50:11 2020 From: john.haxby at oracle.com (John Haxby) Date: Fri, 22 May 2020 10:50:11 +0100 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: > On 20 May 2020, at 23:03, Paul Eggert wrote: > > Tim Parenti's recent emails to the list reminded me that I'd long been meaning to nominate him to be my backup as TZ Coordinator. We should have a backup in case I am no longer available due to retirement or whatever, not that I'm planning to retire any time soon. I would like to start by giving him commit privileges to the development repository on GitHub, so that his contributions can become part of releases more easily. > > Tim has been a longtime and substantial contributor to tzdb, as evidenced by his detailed and careful patches. Although he's mostly worked in the tzdata area, he's also proficient on the code side, as his recent patch proposals demonstrate. He and I have corresponded by email about this and he's indicated his willingness to take on the responsibility. I'd appreciate reactions to Tim's offer to be backup; please respond within the next week. +1 jch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: Message signed with OpenPGP URL: From michael.h.deckers at googlemail.com Fri May 22 12:01:13 2020 From: michael.h.deckers at googlemail.com (Michael H Deckers) Date: Fri, 22 May 2020 12:01:13 +0000 Subject: [tz] Tim Parenti as backup TZ Coordinator? In-Reply-To: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> References: <06afe75b-f24a-b88d-d5b5-c0f158346c5e@cs.ucla.edu> Message-ID: <475f9d7b-4dc7-0e5a-eaed-9bd372b3ecbf@googlemail.com> ? On 2020-05-20 22:03, Paul Eggert wrote: > ?I'd appreciate reactions to Tim's offer to be backup; please respond > within the next week. ? +1 ? Michael Deckers. From gkssarma59 at gmail.com Fri May 22 16:10:29 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Fri, 22 May 2020 21:40:29 +0530 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: we have used this code to get the IANA tz version. public static String getTimezoneDatabaseIANAVersion() { File readmeFile = new File(ZONEINFO_PATH, "README"); File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); if (!readmeFile.exists()) { readmeFile = alternativeReadmeFile; } out read me.txt file contain generated by Gradle Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz means we are using correct tzdata2020a. But still why there is issue? Something wrong with tz db?? regards, sundar On Fri, May 22, 2020 at 9:12 PM Sundar Sarma wrote: > ZoneRulesProvider.getVersions( String zoneId ). > which gives the version used by Java. > > this above code gives the version used by java. > > that is correct. Bu the above code is java.time > > we are using joda.time in our application. > > So could you please tell me that how to get the version used by java in > joda time?? > > thanks, > sundar > > On Thu, May 21, 2020 at 6:39 PM Michael H Deckers < > michael.h.deckers at googlemail.com> wrote: > >> >> On 2020-05-21 12:39, Sundar Sarma wrote: >> >> >> > Still i did not understand why this test case is failing with new 2020a >> tz. >> >> >> The version of the IANA database installed in the operating >> system may well differ from the version used by Java.time. >> The latter can be determined with the method >> ZoneRulesProvider.getVersions?( String zoneId ). >> which gives the version used by Java. >> >> HTH. >> >> Michael Deckers. >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Fri May 22 17:46:16 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Fri, 22 May 2020 11:46:16 -0600 Subject: [tz] Java Installed TZ DB Release Reporting (was: Welcome to the "tz" mailing list) In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> On 2020-05-22 10:10, Sundar Sarma wrote: > we have used this code to get the IANA tz version. > > public static String getTimezoneDatabaseIANAVersion() { > > ? ? ? ? File readmeFile = new File(ZONEINFO_PATH, "README"); > ? ? ? ? File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); > > ? ? ? ? if (!readmeFile.exists()) { > ? ? ? ? ? ? readmeFile = alternativeReadmeFile; > ? ? ? ? } > > out read me.txt file contain > > generated by Gradle > Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz > > means we are using correct tzdata2020a. > > But still why there is issue? Something wrong with tz db?? Just because there is a file present on your system does not mean that the TZ DB data has been successfully or correctly installed in the JVM you are running, unless that data is known to be directly used by your JVM as TZ data. Please consider using the suggested Java statement or command that directly queries your JVM: System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); *OR* $ jshell <<< 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' *OR* $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat *OR* equivalent if you are running other JVMs; you also need to follow up with your Java, JVM, workstation or server support staff to get TZ DB updates successfully and correctly downloaded and installed in the JVMs you and others are running on a regular basis. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From gkssarma59 at gmail.com Fri May 22 20:43:44 2020 From: gkssarma59 at gmail.com (Sundar Sarma) Date: Sat, 23 May 2020 02:13:44 +0530 Subject: [tz] Java Installed TZ DB Release Reporting (was: Welcome to the "tz" mailing list) In-Reply-To: <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> Message-ID: Instead of java.time (System.out.println(java.time.z one.ZoneRulesProvider.getVersions("UTC").keySet());)) ) I want the above code in joda.time. Could you please help me?? I didn't get ZoneRulesProvider.getVersions in joda.time.. On Fri, 22 May 2020, 23:16 Brian Inglis, wrote: > On 2020-05-22 10:10, Sundar Sarma wrote: > > we have used this code to get the IANA tz version. > > > > public static String getTimezoneDatabaseIANAVersion() { > > > > File readmeFile = new File(ZONEINFO_PATH, "README"); > > File alternativeReadmeFile = new File(ZONEINFO_PATH, > "README.txt"); > > > > if (!readmeFile.exists()) { > > readmeFile = alternativeReadmeFile; > > } > > > > out read me.txt file contain > > > > generated by Gradle > > Based on > http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz > > > > means we are using correct tzdata2020a. > > > > But still why there is issue? Something wrong with tz db?? > > Just because there is a file present on your system does not mean that the > TZ DB > data has been successfully or correctly installed in the JVM you are > running, > unless that data is known to be directly used by your JVM as TZ data. > > Please consider using the suggested Java statement or command that directly > queries your JVM: > > > System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); > > *OR* > > $ jshell <<< > > 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' > > *OR* > > $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' > /usr/lib/jvm/*/lib/tzdb.dat > > *OR* > > equivalent if you are running other JVMs; > you also need to follow up with your Java, JVM, workstation or server > support > staff to get TZ DB updates successfully and correctly downloaded and > installed > in the JVMs you and others are running on a regular basis. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Fri May 22 21:15:40 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Fri, 22 May 2020 15:15:40 -0600 Subject: [tz] Joda-time Installed TZ DB Release Reporting and Updating (was: Java Installed TZ DB Release Reporting) In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> Message-ID: You can easily find out the proper places to ask these questions with a simple search for the project Joda-time! It is not on this list which does not support downstream products and derivatives, many of which should not be used in any production system, as they do nothing towards the essential task of updating the data, or providing clear and usable automated processes or documentation about maintaining the data, or providing processes or information about managing it. To find out if it is possible to query the time zone version under Joda time, raise a documentation issue at: https://github.com/JodaOrg/joda-time/issues and request they provide the sample code and add that to their documentation. To update Joda-time TZ data follow the build process at to rebuild the library: https://www.joda.org/joda-time/tz_update.html and raise an operational issue requesting an automated process be added to automatically download, apply, and update the library. As recommended you should have upgraded from this project to java.time when Java 8 was released: https://www.joda.org/joda-time/index.html -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] On 2020-05-22 14:43, Sundar Sarma wrote: > Instead of java.time > (System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());)) > ) > > I want the above code in joda.time. Could you please help me??? > I didn't get ZoneRulesProvider.getVersions in joda.time..? > > > On Fri, 22 May 2020, 23:16 Brian Inglis, > wrote: > > On 2020-05-22 10:10, Sundar Sarma wrote: > > we have used this code to get the IANA tz version. > > > > public static String getTimezoneDatabaseIANAVersion() { > > > > ? ? ? ? File readmeFile = new File(ZONEINFO_PATH, "README"); > > ? ? ? ? File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); > > > > ? ? ? ? if (!readmeFile.exists()) { > > ? ? ? ? ? ? readmeFile = alternativeReadmeFile; > > ? ? ? ? } > > > > out read me.txt file contain > > > > generated by Gradle > > Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz > > > > means we are using correct tzdata2020a. > > > > But still why there is issue? Something wrong with tz db?? > > Just because there is a file present on your system does not mean that the TZ DB > data has been successfully or correctly installed in the JVM you are running, > unless that data is known to be directly used by your JVM as TZ data. > > Please consider using the suggested Java statement or command that directly > queries your JVM: > > System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); > > *OR* > > $ jshell <<< > 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' > > *OR* > > $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat > > *OR* > > equivalent if you are running other JVMs; > you also need to follow up with your Java, JVM, workstation or server support > staff to get TZ DB updates successfully and correctly downloaded and installed > in the JVMs you and others are running on a regular basis. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] From michael.h.deckers at googlemail.com Sat May 23 13:17:35 2020 From: michael.h.deckers at googlemail.com (Michael H Deckers) Date: Sat, 23 May 2020 13:17:35 +0000 Subject: [tz] Welcome to the "tz" mailing list In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> Message-ID: <479d05d0-c3ed-cca2-6db1-b7fdbc2f03e4@googlemail.com> ?? On 2020-05-22 15:42, Sundar Sarma wrote: > So could you please tell me that how to get the version used by java in > joda time?? ?? Joda time uses their own time zone data. I do not ?? think you can ask for the version (but I have not looked ?? into Joda time in ages). You can, however, list the data ?? that Joda time keeps for a time zone by repeatedly calling ?? the method? DateTimeZone.nextTransition(instant). ?? HTH ?? Michael Deckers. From listclient at hayo.de Sun May 24 11:38:57 2020 From: listclient at hayo.de (listclient at hayo.de) Date: Sun, 24 May 2020 13:38:57 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] Message-ID: Hi all, when checking the timezone database version on my OpenSuse 15.1 Linux, I do not get the expected result. hayo at computer:~> sudo zdump --version zdump (tzcode) unknown Installed package: timezone - Time Zone Descriptions Is this a defect of the OpenSuse package or of the IANA code distribution? Regards, Hayo More Details ------------ Technical data: Installierte Version 2020a-lp151.2.9.1 Mo 18 Mai 2020 10:13:45 CEST Sa 23 Mai 2020 20:03:30 CEST System/Base BSD-3-Clause AND SUSE-Public-Domain 1,1 MiB 0 B openSUSE Leap 15.1 openSUSE http://bugs.opensuse.org x86_64 http://www.iana.org/time-zones timezone-2020a-lp151.2.9.1 0 File list: /etc/localtime /usr/bin/tzselect /usr/sbin/zdump /usr/sbin/zic /usr/share/zoneinfo ... Change log: Fr 24 Apr 2020 14:00:00 CEST Marketa Calabkova - timezone update 2020a (bsc#1169582) * Morocco springs forward on 2020-05-31, not 2020-05-24. * Canada's Yukon advanced to -07 year-round on 2020-03-08. * America/Nuuk renamed from America/Godthab. * zic now supports expiration dates for leap second lists. From eggert at cs.ucla.edu Sun May 24 17:19:58 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 24 May 2020 10:19:58 -0700 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: On 5/24/20 4:38 AM, listclient at hayo.de wrote: > sudo zdump --version > zdump (tzcode) unknown > > Installed package: > timezone - Time Zone Descriptions > > Is this a defect of the OpenSuse package or of the IANA code distribution? If you aren't sure, then the answer is "OpenSuse". :-) I suggest filing a bug report with the OpenSuse folks. For what it's worth, on Ubuntu 18.04.4 'zdump --version' outputs "zdump (Ubuntu GLIBC 2.27-3ubuntu1) 2.27" and on Fedora 31 it outputs "zdump (GNU libc) 2.30". From N.Semlali at iam.ma Sun May 24 07:51:25 2020 From: N.Semlali at iam.ma (Semlali Naoufal) Date: Sun, 24 May 2020 07:51:25 +0000 Subject: [tz] Fwd: TR: Morocco : Time Change Message-ID: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Hello, I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. Has the patch below been deployed correctly? For iPhone, the time is not changed. Regards, -----Message d'origine----- De : Paul Eggert Envoy? : mercredi 15 avril 2020 06:26 ? : Semlali Naoufal ; Tim Parenti Cc : Maamar Abdelkader ; Time zone mailing list Objet : Re: Morocco : Time Change Thanks for the heads-up. A proposed patch is attached. Looks like we'll need a new tzdb release soon, since the current release is wrong for Morocco starting May 24. ________________________________ [Description : cid:image002.jpg at 01CC9EE4.44A57D10]Eco ? geste: privil?giez la sauvegarde ?lectronique, si n?cessaire imprimez en recto-verso ________________________________ Ce message et toutes les pi?ces jointes sont adress?s ? l'attention exclusive de leurs destinataires et sont strictement confidentiels. Si vous le recevez par erreur, merci de le d?truire apr?s en avoir inform? l'exp?diteur sans d?lai. Toute divulgation, copie ou usage par une personne autre que son destinataire sont interdits. Maroc Telecom d?cline toute responsabilit? pour toute alt?ration, d?formation ou falsification subie par le message au cours de sa transmission. Retrouvez toutes les informations de Maroc Telecom sur www.iam.ma . ________________________________ This message and its attachments are intended only for the person or entity to which it is addressed and are strictly confidential. If you have received this in error, please delete the material from any computer after having informed the sender. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited. Maroc Telecom accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about Maroc Telecom on www.iam.ma . From eggert at cs.ucla.edu Sun May 24 18:45:19 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 24 May 2020 11:45:19 -0700 Subject: [tz] Morocco time change not working on many Android phones In-Reply-To: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> References: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Message-ID: On 5/24/20 12:51 AM, Semlali Naoufal wrote: > I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. > > Has the patch below been deployed correctly? Yes and no. It depends on your Android phone's support and whether you've updated its software recently and rebooted. Android has a complex relationship with tzdata. According to , time zone data is distributed in Android 10 via an Android Pony Express (APEX) container and in Android 8.1 and 9 via an Android Package (APK), and updates take effect after you reboot your phone. I guess in earlier releases tzdata was just part of the operating system. (If Android is like GNU/Linux it has two copies of tzdata, one for Java and the other for native apps; if so, I suppose it's possible for the two copies to disagree.) So, whether your Android phone works in Morocco right now depends on how well your phone's supplier updated its APEX or APX or OS (depending on how old the phone is) and whether you've rebooted. I just now checked the Android clock application in two recently-rebooted Android phones in my household, and one (a Nokia 6.1 running Android 10 - April security patch) had the wrong time for Morocco, whereas the other (an Essential PH-1 running Android 10 - February security patch) had the correct time. Nokia is pretty good about keeping the Nokia 6.1 up to date, but apparently has not issued an APEX container for tzdb 2020a (or maybe has mistakenly issued both APEX and APX with an out-of-date APX). Essential went out of business in February so it surprised me that its phone's tzdata is up to date; perhaps the APEX updating mechanism is not vendor-specific? I searched online for how this APEX stuff really works and came up empty. I don't know how Google broadcasts the latest APEX version for tzdata, or why the Essential PH-1's tzdata is up-to-date despite not having OS updates since February. Perhaps someone with some Android expertise could chime in. There are two bottom lines here. 1. Your experience will vary depending on who is maintaining your Android phone. 2. The Moroccan government should announce its time zone rules much earlier if it wants more of its people's phones to work correctly. From scolebourne at joda.org Mon May 25 07:28:09 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 25 May 2020 08:28:09 +0100 Subject: [tz] Joda-time Installed TZ DB Release Reporting and Updating (was: Java Installed TZ DB Release Reporting) In-Reply-To: References: <423d6b42-b3df-ebd3-5f34-96cc56bddea9@cs.ucla.edu> <79283fed-0d25-fd76-facf-05ee93e2a535@googlemail.com> <3f62a8d1-b5ee-88f5-bcb8-e64e4a270084@SystematicSw.ab.ca> Message-ID: The list of time-zone database versions can be seen in the release notes: https://www.joda.org/joda-time/changes-report.html Stephen On Fri, 22 May 2020 at 22:16, Brian Inglis wrote: > > You can easily find out the proper places to ask these questions with a simple > search for the project Joda-time! > > It is not on this list which does not support downstream products and > derivatives, many of which should not be used in any production system, as they > do nothing towards the essential task of updating the data, or providing clear > and usable automated processes or documentation about maintaining the data, or > providing processes or information about managing it. > > To find out if it is possible to query the time zone version under Joda time, > raise a documentation issue at: > > https://github.com/JodaOrg/joda-time/issues > > and request they provide the sample code and add that to their documentation. > > To update Joda-time TZ data follow the build process at to rebuild the library: > > https://www.joda.org/joda-time/tz_update.html > > and raise an operational issue requesting an automated process be added to > automatically download, apply, and update the library. > > As recommended you should have upgraded from this project to java.time when Java > 8 was released: > > https://www.joda.org/joda-time/index.html > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > > > On 2020-05-22 14:43, Sundar Sarma wrote: > > Instead of java.time > > (System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());)) > > ) > > > > I want the above code in joda.time. Could you please help me?? > > I didn't get ZoneRulesProvider.getVersions in joda.time.. > > > > > > On Fri, 22 May 2020, 23:16 Brian Inglis, > > wrote: > > > > On 2020-05-22 10:10, Sundar Sarma wrote: > > > we have used this code to get the IANA tz version. > > > > > > public static String getTimezoneDatabaseIANAVersion() { > > > > > > File readmeFile = new File(ZONEINFO_PATH, "README"); > > > File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); > > > > > > if (!readmeFile.exists()) { > > > readmeFile = alternativeReadmeFile; > > > } > > > > > > out read me.txt file contain > > > > > > generated by Gradle > > > Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz > > > > > > means we are using correct tzdata2020a. > > > > > > But still why there is issue? Something wrong with tz db?? > > > > Just because there is a file present on your system does not mean that the TZ DB > > data has been successfully or correctly installed in the JVM you are running, > > unless that data is known to be directly used by your JVM as TZ data. > > > > Please consider using the suggested Java statement or command that directly > > queries your JVM: > > > > System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); > > > > *OR* > > > > $ jshell <<< > > 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' > > > > *OR* > > > > $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat > > > > *OR* > > > > equivalent if you are running other JVMs; > > you also need to follow up with your Java, JVM, workstation or server support > > staff to get TZ DB updates successfully and correctly downloaded and installed > > in the JVMs you and others are running on a regular basis. > > > > -- > > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > > > This email may be disturbing to some readers as it contains > > too much technical detail. Reader discretion is advised. > > [Data in IEC units and prefixes, physical quantities in SI.] From listclient at hayo.de Mon May 25 09:20:09 2020 From: listclient at hayo.de (listclient at hayo.de) Date: Mon, 25 May 2020 11:20:09 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: Am 24.05.20 um 19:19 schrieb Paul Eggert: > On 5/24/20 4:38 AM, listclient at hayo.de wrote: >> sudo zdump --version >> zdump (tzcode) unknown >> >> Installed package: >> timezone - Time Zone Descriptions >> >> Is this a defect of the OpenSuse package or of the IANA code distribution? > > If you aren't sure, then the answer is "OpenSuse". :-) > > I suggest filing a bug report with the OpenSuse folks. opensuse.org and new suse.com both are currently migrating user accounts. In short: I cannot log in to the Suse-Bugzilla. That is why the maintainer from Suse was and is addressed by this thread. M. Calabkova, please take care of this bug. >For what it's worth, on Ubuntu 18.04.4 'zdump --version' outputs >"zdump (Ubuntu GLIBC 2.27-3ubuntu1) 2.27" and on Fedora 31 it outputs >"zdump (GNU libc) 2.30". I expected this result. Thanks for your support. Regards, Hayo From mcalabkova at suse.cz Mon May 25 09:22:05 2020 From: mcalabkova at suse.cz (mcalabkova) Date: Mon, 25 May 2020 11:22:05 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: On 2020-05-24 19:19, Paul Eggert wrote: > On 5/24/20 4:38 AM, listclient at hayo.de wrote: >> sudo zdump --version >> zdump (tzcode) unknown >> >> Installed package: >> timezone - Time Zone Descriptions >> >> Is this a defect of the OpenSuse package or of the IANA code >> distribution? > > If you aren't sure, then the answer is "OpenSuse". :-) indeed :) I found out we were re-making a 'version' file (because of patches) > > I suggest filing a bug report with the OpenSuse folks. For what it's > worth, on > Ubuntu 18.04.4 'zdump --version' outputs "zdump (Ubuntu GLIBC > 2.27-3ubuntu1) > 2.27" and on Fedora 31 it outputs "zdump (GNU libc) 2.30". after fixing the issue above on my computer I get: $ sudo zdump --version zdump (tzcode) 2020a This is different from other distros. Is there any other bug in openSUSE? It looks like the other distros take version info from the last used compiler... Is this correct? Greetings, Marketa From philip at trouble.is Mon May 25 09:31:27 2020 From: philip at trouble.is (Philip Paeps) Date: Mon, 25 May 2020 17:31:27 +0800 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: <56C8137B-FD4F-4F58-B5AF-E7A0AB4FC549@trouble.is> On 2020-05-25 17:22:05 (+0800), mcalabkova wrote: > On 2020-05-24 19:19, Paul Eggert wrote: >> On 5/24/20 4:38 AM, listclient at hayo.de wrote: >>> sudo zdump --version >>> zdump (tzcode) unknown >>> >>> Installed package: >>> timezone - Time Zone Descriptions >>> >>> Is this a defect of the OpenSuse package or of the IANA code >>> distribution? >> >> If you aren't sure, then the answer is "OpenSuse". :-) > > indeed :) I found out we were re-making a 'version' file (because of > patches) > >> >> I suggest filing a bug report with the OpenSuse folks. For what it's >> worth, on >> Ubuntu 18.04.4 'zdump --version' outputs "zdump (Ubuntu GLIBC >> 2.27-3ubuntu1) >> 2.27" and on Fedora 31 it outputs "zdump (GNU libc) 2.30". > > after fixing the issue above on my computer I get: > > $ sudo zdump --version > zdump (tzcode) 2020a > > This is different from other distros. Is there any other bug in > openSUSE? It > looks like the other distros take version info from the last used > compiler... > Is this correct? On FreeBSD and macOS, `zdump --version` returns the version of the zdump program, respectively: zdump: @(#)zdump.c 8.10 (FreeBSD) zdump: @(#)zdump.c 7.31 (macOS) Arguably, your update to OpenSUSE is more useful! Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises -------------- next part -------------- An HTML attachment was scrubbed... URL: From schwab at linux-m68k.org Mon May 25 09:50:31 2020 From: schwab at linux-m68k.org (Andreas Schwab) Date: Mon, 25 May 2020 11:50:31 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: (mcalabkova@suse.cz's message of "Mon, 25 May 2020 11:22:05 +0200") References: Message-ID: <871rn8ny1k.fsf@igel.home> On Mai 25 2020, mcalabkova wrote: > after fixing the issue above on my computer I get: > > $ sudo zdump --version > zdump (tzcode) 2020a > > This is different from other distros. Is there any other bug in openSUSE? > It > looks like the other distros take version info from the last used > compiler... You could set PACKAGE from %distribution, similar to what binutils and gdb do. Also, it would be good to set BUGEMAIL. Andreas. -- Andreas Schwab, schwab at linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From kre at munnari.OZ.AU Mon May 25 10:35:24 2020 From: kre at munnari.OZ.AU (Robert Elz) Date: Mon, 25 May 2020 17:35:24 +0700 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: <56C8137B-FD4F-4F58-B5AF-E7A0AB4FC549@trouble.is> References: <56C8137B-FD4F-4F58-B5AF-E7A0AB4FC549@trouble.is> Message-ID: <14589.1590402924@jinx.noi.kre.to> Date: Mon, 25 May 2020 17:31:27 +0800 From: "Philip Paeps" Message-ID: <56C8137B-FD4F-4F58-B5AF-E7A0AB4FC549 at trouble.is> | On FreeBSD and macOS, `zdump --version` returns [...] On NetBSD (-current) netbsd# zdump --version zdump (tzcode) 2019b (we don't update tzcode all that frequently, tzdata on the other hand is 2020a) kre From mcalabkova at suse.cz Mon May 25 12:20:15 2020 From: mcalabkova at suse.cz (mcalabkova) Date: Mon, 25 May 2020 14:20:15 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: <871rn8ny1k.fsf@igel.home> References: <871rn8ny1k.fsf@igel.home> Message-ID: <58d32da5f41e02e2e2050d80d713c612@suse.cz> On 2020-05-25 11:50, Andreas Schwab wrote: > On Mai 25 2020, mcalabkova wrote: > >> after fixing the issue above on my computer I get: >> >> $ sudo zdump --version >> zdump (tzcode) 2020a >> >> This is different from other distros. Is there any other bug in >> openSUSE? >> It >> looks like the other distros take version info from the last used >> compiler... > > You could set PACKAGE from %distribution, similar to what binutils and > gdb do. Also, it would be good to set BUGEMAIL. I have tried it (I have also set it to print a real package name) and I got: $ sudo zdump --version zdump (timezone; Base:System) 2020a (Base:System is the repository in which I locally build the package.) I personally dislike it, after reading the discussion I would stay with simple tzcode (the previous result). I will set BUGEMAIL to opensuse-support at opensuse.org, thanks. Hayo, are you satisfied with this solution? Greetings, Marketa From Brian.Inglis at SystematicSw.ab.ca Mon May 25 13:14:19 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Mon, 25 May 2020 07:14:19 -0600 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: Message-ID: <93de2c3d-67ef-a2c9-1e81-a64515eac83b@SystematicSw.ab.ca> On 2020-05-25 03:22, mcalabkova wrote: > On 2020-05-24 19:19, Paul Eggert wrote: >> On 5/24/20 4:38 AM, listclient at hayo.de wrote: >>> sudo zdump --version >>> zdump (tzcode) unknown >>> >>> Installed package: >>> timezone - Time Zone Descriptions >>> >>> Is this a defect of the OpenSuse package or of the IANA code distribution? >> >> If you aren't sure, then the answer is "OpenSuse". :-) > > indeed :) I found out we were re-making a 'version' file (because of patches) > >> >> I suggest filing a bug report with the OpenSuse folks. For what it's worth, on >> Ubuntu 18.04.4 'zdump --version' outputs "zdump (Ubuntu GLIBC 2.27-3ubuntu1) >> 2.27" and on Fedora 31 it outputs "zdump (GNU libc) 2.30". > > after fixing the issue above on my computer I get: > > $ sudo zdump --version > zdump (tzcode) 2020a > > This is different from other distros. Is there any other bug in openSUSE? It > looks like the other distros take version info from the last used compiler... > Is this correct? A number of distros do not use tzcode directly, but have their own release, based on their libc TZ and locale handling, applying patches based on tzcode patches, or based on BSD to allow use and inclusion in commercial or proprietary products, often RT or embedded systems for microcontrollers, with tailored support for data, functionality, size. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From Brian.Inglis at SystematicSw.ab.ca Mon May 25 13:14:26 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Mon, 25 May 2020 07:14:26 -0600 Subject: [tz] Morocco time change not working on many Android phones In-Reply-To: References: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Message-ID: <7eae207d-6197-4c33-5828-f60bbb2b8214@SystematicSw.ab.ca> On 2020-05-24 12:45, Paul Eggert wrote: > On 5/24/20 12:51 AM, Semlali Naoufal wrote: >> I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. >> >> Has the patch below been deployed correctly? > > Yes and no. It depends on your Android phone's support and whether you've > updated its software recently and rebooted. > > Android has a complex relationship with tzdata. According to > , time zone data > is distributed in Android 10 via an Android Pony Express (APEX) container and in > Android 8.1 and 9 via an Android Package (APK), and updates take effect after > you reboot your phone. I guess in earlier releases tzdata was just part of the > operating system. (If Android is like GNU/Linux it has two copies of tzdata, one > for Java and the other for native apps; if so, I suppose it's possible for the > two copies to disagree.) > > So, whether your Android phone works in Morocco right now depends on how well > your phone's supplier updated its APEX or APX or OS (depending on how old the > phone is) and whether you've rebooted. I just now checked the Android clock > application in two recently-rebooted Android phones in my household, and one (a > Nokia 6.1 running Android 10 - April security patch) had the wrong time for > Morocco, whereas the other (an Essential PH-1 running Android 10 - February > security patch) had the correct time. > > Nokia is pretty good about keeping the Nokia 6.1 up to date, but apparently has > not issued an APEX container for tzdb 2020a (or maybe has mistakenly issued both > APEX and APX with an out-of-date APX). Essential went out of business in > February so it surprised me that its phone's tzdata is up to date; perhaps the > APEX updating mechanism is not vendor-specific? > > I searched online for how this APEX stuff really works and came up empty. I > don't know how Google broadcasts the latest APEX version for tzdata, or why the > Essential PH-1's tzdata is up-to-date despite not having OS updates since > February. Perhaps someone with some Android expertise could chime in. > > There are two bottom lines here. > > 1. Your experience will vary depending on who is maintaining your Android phone. > > 2. The Moroccan government should announce its time zone rules much earlier if > it wants more of its people's phones to work correctly. In many cases, it is up to the phone hardware vendor e.g. Samsung or network vendor e.g. telco, who customize Android for their hardware platform or their network infrastructure, to customize and forward security and system updates. Apple is good about this for iOS and many old phones still get updates, until they are so old that certain updates may not be applied to them. Google is trying to promote and bypass vendors for security and system updates, as Android systems have a poor rep for security and updates: maybe 1.5-3 years support from release of a model from a vendor, and limited support from telcos, concentrating on recently sold sets. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From listclient at hayo.de Mon May 25 12:49:29 2020 From: listclient at hayo.de (listclient at hayo.de) Date: Mon, 25 May 2020 14:49:29 +0200 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: <58d32da5f41e02e2e2050d80d713c612@suse.cz> References: <871rn8ny1k.fsf@igel.home> <58d32da5f41e02e2e2050d80d713c612@suse.cz> Message-ID: <2dec48f7-2b64-ded2-9a99-0c8c64b7a1e3@hayo.de> Am 25.05.20 um 14:20 schrieb mcalabkova: > On 2020-05-25 11:50, Andreas Schwab wrote: >> On Mai 25 2020, mcalabkova wrote: >> >>> after fixing the issue above on my computer I get: >>> >>> $ sudo zdump --version >>> zdump (tzcode) 2020a >>> >>> This is different from other distros. Is there any other bug in >>> openSUSE? >>> It >>> looks like the other distros take version info from the last used >>> compiler... >> >> You could set PACKAGE from %distribution, similar to what binutils and >> gdb do.? Also, it would be good to set BUGEMAIL. > > I have tried it (I have also set it to print a real package name) and I > got: > > $ sudo zdump --version > zdump (timezone; Base:System) 2020a > > (Base:System is the repository in which I locally build the package.) > > I personally dislike it, after reading the discussion I would stay with > simple tzcode (the previous result). > > I will set BUGEMAIL to opensuse-support at opensuse.org, thanks. > > Hayo, are you satisfied with this solution? Marketa, from the perspective of the OpenSuse user I am fully satisfied with the solution. In fact I expected 'sudo zdump --version' to return the database version. But the man page is unspecific in its description. >From the perspective of the zdump user, the current situation is not that good. I think all distributions should return similar output. And the output should contain the tzdata version. Only that way it is possible to evaluate the output in portable scripts. Proposal (for a future version >2020a): $ sudo zdump --version zdump (GLIBC 2.28) - tzdata 2020c > > Greetings, > Marketa Greetings, Hayo From enh at google.com Tue May 26 15:37:09 2020 From: enh at google.com (enh) Date: Tue, 26 May 2020 08:37:09 -0700 Subject: [tz] Morocco time change not working on many Android phones In-Reply-To: References: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Message-ID: On Sun, May 24, 2020 at 11:45 AM Paul Eggert wrote: > > On 5/24/20 12:51 AM, Semlali Naoufal wrote: > > I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. > > > > Has the patch below been deployed correctly? > > Yes and no. It depends on your Android phone's support and whether you've > updated its software recently and rebooted. > > Android has a complex relationship with tzdata. According to > , time zone data > is distributed in Android 10 via an Android Pony Express (APEX) container and in > Android 8.1 and 9 via an Android Package (APK), and updates take effect after > you reboot your phone. I guess in earlier releases tzdata was just part of the > operating system. (If Android is like GNU/Linux it has two copies of tzdata, one > for Java and the other for native apps; if so, I suppose it's possible for the > two copies to disagree.) like Linux, no: ART doesn't have its own copy of tzdata. are there two copies? yes: icu has its own slightly different database built from tzdata, in addition the "normal" (it's just all the tzdata files concatenated with a small header) tzdata. but they're both in the apk or apex. > So, whether your Android phone works in Morocco right now depends on how well > your phone's supplier updated its APEX or APX or OS (depending on how old the > phone is) and whether you've rebooted. I just now checked the Android clock > application in two recently-rebooted Android phones in my household, and one (a > Nokia 6.1 running Android 10 - April security patch) had the wrong time for > Morocco, whereas the other (an Essential PH-1 running Android 10 - February > security patch) had the correct time. > > Nokia is pretty good about keeping the Nokia 6.1 up to date, but apparently has > not issued an APEX container for tzdb 2020a (or maybe has mistakenly issued both > APEX and APX with an out-of-date APX). Essential went out of business in > February so it surprised me that its phone's tzdata is up to date; perhaps the > APEX updating mechanism is not vendor-specific? > > I searched online for how this APEX stuff really works and came up empty. I > don't know how Google broadcasts the latest APEX version for tzdata, or why the > Essential PH-1's tzdata is up-to-date despite not having OS updates since > February. Perhaps someone with some Android expertise could chime in. apexes, like apks, are updated via the Play Store. > There are two bottom lines here. > > 1. Your experience will vary depending on who is maintaining your Android phone. > > 2. The Moroccan government should announce its time zone rules much earlier if > it wants more of its people's phones to work correctly. From nfuller at google.com Wed May 27 12:03:40 2020 From: nfuller at google.com (Neil Fuller) Date: Wed, 27 May 2020 13:03:40 +0100 Subject: [tz] Morocco time change not working on many Android phones In-Reply-To: References: <88322457-36ae-4e90-90cb-91c870e7baa9@email.android.com> Message-ID: To expand on what enh@ said and provide some more context: One of my responsibilities on Android is the time zone data source-code updates. I can confirm it's complicated! The short answer is that the Morocco change didn't give maintainers a lot of time to react. The number of devices, manufacturers and users involved for Android alone is quite humbling! Literally billions of devices, millions of users, spread over thousands of different types of device. I am a software engineer, so I can provide some technical information around Android tzdb updates for future reference (see text below my name). Paul is correct: it is my understanding that the Essential PH-1 device is using the Google-managed APEX update mechanism. I hope the information below helps explain what the situation is. As more devices move to the APEX update mechanism we should continue to see improvements here. That said, I think four working weeks from tzdb release to device is always going to be difficult with so many parties and devices involved. Neil. -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902 ------------- The Android OS has two main copies of time zone data: one that is used by Android's libc (bionic) and its java.util.TimeZone class, and a copy associated with Android's embedded of International Components for Unicode libraries (ICU4C and ICU4J). ICU has additional information like translations for zone names and other time zone metadata that need to be updated. Both copies are updated when I produce source code updates, though manufacturers can create their own source code updates if they wish. We alert partners to source updates for recent releases (currently from 8.0/Oreo up to Android 10) and we make them available to all via the AOSP project. For example, https://android-review.googlesource.com/q/topic:%22tzdb2020a_pie-dev%22+(status:open%20OR%20status:merged) is the Android 9 backport of the tzdb 2020a update. For many devices (i.e. those before Android 10, the Q3 2019 release) the device update process is entirely handled by the manufacturer, either via a full "over the air" (OTA) system image update, via the APK mechanism linked by Paul, or a proprietary mechanism. All these mechanisms the manufacturer is responsible for. For Android 10 devices that support APEX updates, Google now manages the update via Google Play System Update (internal name Project Mainline ). For devices that don't, the information for earlier releases is currently still true. I know the Android Mainline folks handling building / signing / QA and partner coordination for the Google-managed APEX update have been working hard to get an APEX update out in time for the Morocco offset change. For any update there still needs to be a lot of coordination between Google and the manufacturer partners. Google rolls out updates like this very carefully. My understanding is that the update was available to 100% of Mainline updatable devices by Friday 22nd May. Yesterday morning (26th May) I checked my personal Android 10 device (which I know does have Google-managed APEX updates), and found that it had updated to 2020a, but it did take a manual reboot by me before that was the case. On Tue, 26 May 2020 at 16:37, enh via tz wrote: > On Sun, May 24, 2020 at 11:45 AM Paul Eggert wrote: > > > > On 5/24/20 12:51 AM, Semlali Naoufal wrote: > > > I would like to inform you that the time has been advanced by one hour > today on Android Smartphones while the time change should not be made until > 31.05.2020 as already reported. > > > > > > Has the patch below been deployed correctly? > > > > Yes and no. It depends on your Android phone's support and whether you've > > updated its software recently and rebooted. > > > > Android has a complex relationship with tzdata. According to > > , time > zone data > > is distributed in Android 10 via an Android Pony Express (APEX) > container and in > > Android 8.1 and 9 via an Android Package (APK), and updates take effect > after > > you reboot your phone. I guess in earlier releases tzdata was just part > of the > > operating system. (If Android is like GNU/Linux it has two copies of > tzdata, one > > for Java and the other for native apps; if so, I suppose it's possible > for the > > two copies to disagree.) > > like Linux, no: ART doesn't have its own copy of tzdata. > > are there two copies? yes: icu has its own slightly different database > built from tzdata, in addition the "normal" (it's just all the tzdata > files concatenated with a small header) tzdata. but they're both in > the apk or apex. > > > So, whether your Android phone works in Morocco right now depends on how > well > > your phone's supplier updated its APEX or APX or OS (depending on how > old the > > phone is) and whether you've rebooted. I just now checked the Android > clock > > application in two recently-rebooted Android phones in my household, and > one (a > > Nokia 6.1 running Android 10 - April security patch) had the wrong time > for > > Morocco, whereas the other (an Essential PH-1 running Android 10 - > February > > security patch) had the correct time. > > > > Nokia is pretty good about keeping the Nokia 6.1 up to date, but > apparently has > > not issued an APEX container for tzdb 2020a (or maybe has mistakenly > issued both > > APEX and APX with an out-of-date APX). Essential went out of business in > > February so it surprised me that its phone's tzdata is up to date; > perhaps the > > APEX updating mechanism is not vendor-specific? > > > > I searched online for how this APEX stuff really works and came up > empty. I > > don't know how Google broadcasts the latest APEX version for tzdata, or > why the > > Essential PH-1's tzdata is up-to-date despite not having OS updates since > > February. Perhaps someone with some Android expertise could chime in. > > apexes, like apks, are updated via the Play Store. > > > There are two bottom lines here. > > > > 1. Your experience will vary depending on who is maintaining your > Android phone. > > > > 2. The Moroccan government should announce its time zone rules much > earlier if > > it wants more of its people's phones to work correctly. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naela.sarras at iana.org Wed May 27 20:52:06 2020 From: naela.sarras at iana.org (Naela Sarras) Date: Wed, 27 May 2020 20:52:06 +0000 Subject: [tz] FW: [Ext] The TZ Coordination Message-ID: Dear Paul, Please see the note below from our colleagues in Morocco regarding the upcoming timezone change for Morocco. Best regards, Naela Naela Sarras Director, IANA Operations ICANN From: EL MAAYATI Afaf Date: Wednesday, May 27, 2020 at 12:01 PM To: Naela Sarras Cc: BENLEMLIH Hamida Subject: [Ext] The TZ Coordination Dear Naela, I hope this email finds you well, safe and healthy. Actually, I have a request concerning the configuration of the Time-Zone for Morocco. In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it?s mentionned that a program will be running to implement the transition dates: [cid:image001.jpg at 01D6342E.01C70B10] Currently we are implementing GMT and we will move to GMT+1 next Sunday, May 31. So, if possible, would you please help to get in touch with Mr. Paul Eggert, in order to have the procedure to notify IANA officially, from a governmental source, with the changes of TZ in Morocco. Thank you in advance for your feedback and for your habitual support. Best Regards, Afaf ________________________________ Ce message, son contenu et toutes les pi?ces jointes sont adress?s ? l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils rel?vent de la correspondance priv?e. Toute publication, utilisation ou diffusion, m?me partielle, par des personnes autres que les destinataires est interdite et doit ?tre autoris?e par l'Agence Nationale de R?glementation des T?l?communications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le d?truire apr?s en avoir inform? son exp?diteur sans d?lai. L?ANRT d?cline toute responsabilit? pour toute alt?ration, d?formation ou falsification subi par le message et ses pi?ces jointes au cours de leur transmission. Retrouvez toutes les informations de l?ANRT sur son site Web ? l?adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ ?? ??? ??????? ???????? ????????? ????? ????? ????? ?????? ???? ?????? ???? ????? ??? ???? ????????? ??? ????? ?????. ????? ???? ???? ??? ?? ??????? ?? ??? ??? ?????? ?????? ???? ??????? ?? ??? ????? ??? ?????? ????? ?? ?? ??? ??????? ???? ?? ??? ??????? ??????? ?????? ????????? (??????? ????????. ?? ???? ?? ??? ?????? ??? ??????? ?? ???? ?????? ???? ???? ????? ??? ??????? ???? ??? ????? ????? ?????? ???? ????. ??? ????? ??????? ??????? ?????? ????????? ?? ??????? ?? ?? ????? ?? ????? ?? ????? ?? ???? ?????? ??????? ?? ????????? ???? ????? ???????. ?????? ?? ?????????? ???? ??????? ??? ?????? ?????????? ??????? ??????? ?????? ????????? : http://www.anrt.ma. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 81051 bytes Desc: image001.jpg URL: From eggert at cs.ucla.edu Thu May 28 00:48:28 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Wed, 27 May 2020 17:48:28 -0700 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: References: Message-ID: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> >From Afaf El Maayati (2020-05-27): > In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it?s mentioned that a program will be running to implement the transition dates That commentary refers to a program that I ran on April 14; it predicted daylight-saving transitions for Morocco for the years 2021 through 2087, and I installed those predictions into tzdb 2020a. We don't know now whether those predictions are correct, since the government of Morocco hasn't published plans for 2021 and later and it might change its mind before next year. Even so, the tzdb tradition is to predict plausible transitions that are more likely to be correct than a prediction of no transitions at all. > we will move to GMT+1 next Sunday, May 31. Yes, that transition is in tzdb 2020a (the current tzdb release), so tzdb should not need any changes for it. Currently, devices based on out-of-date tzdb releases are off by an hour for Morocco; these devices should start being correct on May 31. Devices based on tzdb 2020a should be correct both now and after May 31. PS. Of the devices I have ready access to, many are out-of-date and are therefore showing incorrect time for Morocco because it takes more than a few weeks to propagate tzdb changes via manufacturers and suppliers to the billions of devices on the planet. My up-to-date devices are running: * Android 10 with APEX updates from Google Play Store * iOS 13.3.1 * macOS 10.14.6 * Ubuntu 18.04.3 From eggert at cs.ucla.edu Thu May 28 07:23:27 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 28 May 2020 00:23:27 -0700 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: <2dec48f7-2b64-ded2-9a99-0c8c64b7a1e3@hayo.de> References: <871rn8ny1k.fsf@igel.home> <58d32da5f41e02e2e2050d80d713c612@suse.cz> <2dec48f7-2b64-ded2-9a99-0c8c64b7a1e3@hayo.de> Message-ID: On 5/25/20 5:49 AM, listclient at hayo.de wrote: > From the perspective of the zdump user, the current situation is not > that good. I think all distributions should return similar output. And > the output should contain the tzdata version. That's not what the --version flag is for. --version is supposed to output the version number of the program, not of any data. This is the common meaning of "--version" across a wide variety of programs. Many distributions update tzcode (the source code for zdump) more rarely than tzdata, and it's helpful to keep the two version numbers distinct in that case. zdump is intended to be portable to any system that conforms to POSIX, and since there's no POSIX-portable way to find out the tzdata version, zdump doesn't do that. There might not be any tzdata at all, and zdump is still supposed to work. Though perhaps this zdump design goal should change at some point.... From clive at davros.org Thu May 28 07:34:09 2020 From: clive at davros.org (Clive D.W. Feather) Date: Thu, 28 May 2020 08:34:09 +0100 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> Message-ID: <20200528073409.GA72460@davros.org> Paul Eggert said: > We don't know now whether those predictions are correct, since the government of > Morocco hasn't published plans for 2021 and later and it might change its mind > before next year. Even so, the tzdb tradition is to predict plausible > transitions that are more likely to be correct than a prediction of no > transitions at all. Would this be a good opportunity to engage with the government of Morocco to encourage them to give more warning? -- Clive D.W. Feather | If you lie to the compiler, Email: clive at davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 From guy at alum.mit.edu Thu May 28 09:39:47 2020 From: guy at alum.mit.edu (Guy Harris) Date: Thu, 28 May 2020 02:39:47 -0700 Subject: [tz] zdump --version reports "unknown" on OpenSuse 15.1 [2020a] In-Reply-To: References: <871rn8ny1k.fsf@igel.home> <58d32da5f41e02e2e2050d80d713c612@suse.cz> <2dec48f7-2b64-ded2-9a99-0c8c64b7a1e3@hayo.de> Message-ID: On May 28, 2020, at 12:23 AM, Paul Eggert wrote: > That's not what the --version flag is for. --version is supposed to output the > version number of the program, not of any data. This is the common meaning of > "--version" across a wide variety of programs. Yes. For example, the GNU coding standard says of --version: https://www.gnu.org/prep/standards/standards.html#g_t_002d_002dversion "The standard --version option should direct the program to print information about its name, version, origin and legal status, all on standard output, and then exit successfully." > zdump is intended to be portable to any system that conforms to POSIX, and since > there's no POSIX-portable way to find out the tzdata version, zdump doesn't do > that. There might not be any tzdata at all, and zdump is still supposed to work. > Though perhaps this zdump design goal should change at some point.... And if there *were* a POSIX-portable way to find out the tzdata version, zdump should, *if* there's tzdata from which to find the version using the POSIX-portable way in question, have a *different* flag, e.g. --tzdata-version, to tell it to report that version. From eggert at cs.ucla.edu Thu May 28 16:47:41 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 28 May 2020 09:47:41 -0700 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> Message-ID: <4970e290-8f69-a4e6-7158-c682146f038d@cs.ucla.edu> On 5/28/20 3:41 AM, EL MAAYATI Afaf wrote: > we need to know if there is a procedure to notify IANA (TZ Coordination) officially, from a governmental source, with the official dates of TZ changes in Morocco. The procedure is to send email to tz at iana.org with official citations, preferably with pointers to copies in English since the mailing list is in English. For best results, give one years' notice before the dates of change. For more details, please see: https://data.iana.org/time-zones/tz-link.html#changes From jlladonosa at gmail.com Wed May 27 08:02:14 2020 From: jlladonosa at gmail.com (josep lladonosa capell) Date: Wed, 27 May 2020 10:02:14 +0200 Subject: [tz] Typo in a 1900 date of europe tz file Message-ID: Hello, I was just reading the europe tz file and found a typo. The comment in the file gives the date 26/6/1900 but in fact it was July (7) not June (6). In the same text there is a reference to the official document of 26/7/1900. Attached you will find the patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: myfix.patch Type: text/x-patch Size: 526 bytes Desc: not available URL: From fw at deneb.enyo.de Sat May 30 14:00:24 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 30 May 2020 16:00:24 +0200 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <20200528073409.GA72460@davros.org> (Clive D. W. Feather's message of "Thu, 28 May 2020 08:34:09 +0100") References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> Message-ID: <87y2p98qvb.fsf@mid.deneb.enyo.de> * Clive D. W. Feather: > Paul Eggert said: >> We don't know now whether those predictions are correct, since the government of >> Morocco hasn't published plans for 2021 and later and it might change its mind >> before next year. Even so, the tzdb tradition is to predict plausible >> transitions that are more likely to be correct than a prediction of no >> transitions at all. > > Would this be a good opportunity to engage with the government of Morocco > to encourage them to give more warning? My understanding is that at present, they don't know themselves in advance. They would have to redefine the criteria to something based exclusively on astronomical calculations, probably giving up the alignment with Ramadan. I don't know if this would be feasible. From eggert at cs.ucla.edu Sat May 30 23:03:54 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sat, 30 May 2020 16:03:54 -0700 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <87y2p98qvb.fsf@mid.deneb.enyo.de> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> Message-ID: <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> On 5/30/20 7:00 AM, Florian Weimer wrote: >> Would this be a good opportunity to engage with the government of Morocco >> to encourage them to give more warning? > My understanding is that at present, they don't know themselves in > advance. Yes, I think you're right. > They would have to redefine the criteria to something based > exclusively on astronomical calculations That shouldn't be necessary, as they're using a conservative approximation; that is, it's OK if their approximation is a bit off because all they need to do is to bracket the actual Ramadan rather than predict its Gregorian dates exactly. If they had an algorithm they could publish it and we could use it. And it would be technically feasible for them to have an algorithm; see the Morocco-prediction code in the tzdb 'africa' file for an example algorithm. Admittedly there are obstacles to getting all this to work. That being said, I suspect that the obstacles here are administrative, not religious or technical. We needed a tzdb 2020a because in 2019c I had predicted a tighter bound around the actual Ramadan, whereas the Moroccan authorities evidently wanted a looser bound. That is, Ramadan ended May 23 in Morocco, and tzdb 2019c had predicted May 24 for the spring-forward transition whereas the Moroccan government decided on May 31. PS. In about three hours the discrepancy will become moot, as Morocco will do its end-of-Ramadan spring-forward and after that the 2019c clocks will agree with the 2020a clocks. From fw at deneb.enyo.de Sun May 31 11:09:03 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 31 May 2020 13:09:03 +0200 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> (Paul Eggert's message of "Sat, 30 May 2020 16:03:54 -0700") References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> Message-ID: <877dws744w.fsf@mid.deneb.enyo.de> * Paul Eggert: > On 5/30/20 7:00 AM, Florian Weimer wrote: >>> Would this be a good opportunity to engage with the government of Morocco >>> to encourage them to give more warning? >> My understanding is that at present, they don't know themselves in >> advance. > > Yes, I think you're right. > >> They would have to redefine the criteria to something based >> exclusively on astronomical calculations > > That shouldn't be necessary, as they're using a conservative > approximation; that is, it's OK if their approximation is a bit off > because all they need to do is to bracket the actual Ramadan rather > than predict its Gregorian dates exactly. If they had an algorithm > they could publish it and we could use it. And it would be > technically feasible for them to have an algorithm; see the > Morocco-prediction code in the tzdb 'africa' file for an example > algorithm. It looks like the algorithm predicted correctly the data of Eid al-Fitr as 24 May, but the derivation of the end date from that is suspicious. I think it would make more sense if the time change does not happen on Eid itself. A rule like this would ensure that Eid still uses the same time as Ramadan in every year, which is likely what people expect. From milamberspace at gmail.com Sun May 31 14:03:50 2020 From: milamberspace at gmail.com (Milamber) Date: Sun, 31 May 2020 15:03:50 +0100 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <877dws744w.fsf@mid.deneb.enyo.de> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> Message-ID: <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> On 5/31/20 12:09 PM, Florian Weimer wrote: > * Paul Eggert: > >> On 5/30/20 7:00 AM, Florian Weimer wrote: >>>> Would this be a good opportunity to engage with the government of Morocco >>>> to encourage them to give more warning? >>> My understanding is that at present, they don't know themselves in >>> advance. >> Yes, I think you're right. >> >>> They would have to redefine the criteria to something based >>> exclusively on astronomical calculations >> That shouldn't be necessary, as they're using a conservative >> approximation; that is, it's OK if their approximation is a bit off >> because all they need to do is to bracket the actual Ramadan rather >> than predict its Gregorian dates exactly. If they had an algorithm >> they could publish it and we could use it. And it would be >> technically feasible for them to have an algorithm; see the >> Morocco-prediction code in the tzdb 'africa' file for an example >> algorithm. > It looks like the algorithm predicted correctly the data of Eid > al-Fitr as 24 May, but the derivation of the end date from that is > suspicious. I think it would make more sense if the time change does > not happen on Eid itself. In Morocco (where I live), the end of Ramadan (arabic month) is follow by the Eid al-Fitr, and concretely it's 1 or 2 day off for the people (with traditional visiting of family, big lunches/diners, etc.). So for this year the astronomical calculations don't include the following 2 day off in the calc. This 2 days have fall in a Sunday/Monday, so it's not acceptable by people to have a time shift during these 2 day off. Perhaps, you can modify the (predict) rules for next years : if the end of Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a weekend), the next time shift will be the next weekend. > A rule like this would ensure that Eid > still uses the same time as Ramadan in every year, which is likely > what people expect. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mj1856 at hotmail.com Sun May 31 17:25:10 2020 From: mj1856 at hotmail.com (Matt Johnson-Pint) Date: Sun, 31 May 2020 17:25:10 +0000 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de>, <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> Message-ID: Forgive me if this is in any way ignorant, but why must the DST transitions align so precisely with Ramadan? Would it not be sufficient if the dates for the time change were predictable as long as the switch to GMT occurred sometime before the start of Ramadan and the switch back to GMT+1 occurred sometime after? Is there a political, social, or religious reason why they must be so exactly aligned? -Matt ________________________________ From: tz on behalf of Milamber Sent: Sunday, May 31, 2020 7:03:50 AM To: Florian Weimer ; Paul Eggert Cc: Time zone mailing list Subject: Re: [tz] FW: [Ext] The TZ Coordination On 5/31/20 12:09 PM, Florian Weimer wrote: * Paul Eggert: On 5/30/20 7:00 AM, Florian Weimer wrote: Would this be a good opportunity to engage with the government of Morocco to encourage them to give more warning? My understanding is that at present, they don't know themselves in advance. Yes, I think you're right. They would have to redefine the criteria to something based exclusively on astronomical calculations That shouldn't be necessary, as they're using a conservative approximation; that is, it's OK if their approximation is a bit off because all they need to do is to bracket the actual Ramadan rather than predict its Gregorian dates exactly. If they had an algorithm they could publish it and we could use it. And it would be technically feasible for them to have an algorithm; see the Morocco-prediction code in the tzdb 'africa' file for an example algorithm. It looks like the algorithm predicted correctly the data of Eid al-Fitr as 24 May, but the derivation of the end date from that is suspicious. I think it would make more sense if the time change does not happen on Eid itself. In Morocco (where I live), the end of Ramadan (arabic month) is follow by the Eid al-Fitr, and concretely it's 1 or 2 day off for the people (with traditional visiting of family, big lunches/diners, etc.). So for this year the astronomical calculations don't include the following 2 day off in the calc. This 2 days have fall in a Sunday/Monday, so it's not acceptable by people to have a time shift during these 2 day off. Perhaps, you can modify the (predict) rules for next years : if the end of Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a weekend), the next time shift will be the next weekend. A rule like this would ensure that Eid still uses the same time as Ramadan in every year, which is likely what people expect. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoidsoft at gmail.com Sun May 31 18:22:23 2020 From: zoidsoft at gmail.com (Zoid Soft) Date: Sun, 31 May 2020 14:22:23 -0400 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> Message-ID: <9552C1BF-C837-46D0-B80E-DA0EDFE556D7@gmail.com> Astrologers have been significant contributors to this list. > On May 31, 2020, at 1:25 PM, Matt Johnson-Pint wrote: > > Forgive me if this is in any way ignorant, but why must the DST transitions align so precisely with Ramadan? Would it not be sufficient if the dates for the time change were predictable as long as the switch to GMT occurred sometime before the start of Ramadan and the switch back to GMT+1 occurred sometime after? Is there a political, social, or religious reason why they must be so exactly aligned? > > -Matt > From: tz on behalf of Milamber > Sent: Sunday, May 31, 2020 7:03:50 AM > To: Florian Weimer ; Paul Eggert > Cc: Time zone mailing list > Subject: Re: [tz] FW: [Ext] The TZ Coordination > > > > On 5/31/20 12:09 PM, Florian Weimer wrote: >> * Paul Eggert: >> >>> On 5/30/20 7:00 AM, Florian Weimer wrote: >>>>> Would this be a good opportunity to engage with the government of Morocco >>>>> to encourage them to give more warning? >>>> My understanding is that at present, they don't know themselves in >>>> advance. >>> Yes, I think you're right. >>> >>>> They would have to redefine the criteria to something based >>>> exclusively on astronomical calculations >>> That shouldn't be necessary, as they're using a conservative >>> approximation; that is, it's OK if their approximation is a bit off >>> because all they need to do is to bracket the actual Ramadan rather >>> than predict its Gregorian dates exactly. If they had an algorithm >>> they could publish it and we could use it. And it would be >>> technically feasible for them to have an algorithm; see the >>> Morocco-prediction code in the tzdb 'africa' file for an example >>> algorithm. >> It looks like the algorithm predicted correctly the data of Eid >> al-Fitr as 24 May, but the derivation of the end date from that is >> suspicious. I think it would make more sense if the time change does >> not happen on Eid itself. > > > In Morocco (where I live), the end of Ramadan (arabic month) is follow by the Eid al-Fitr, and concretely it's 1 or 2 day off for the people (with traditional visiting of family, big lunches/diners, etc.). So for this year the astronomical calculations don't include the following 2 day off in the calc. This 2 days have fall in a Sunday/Monday, so it's not acceptable by people to have a time shift during these 2 day off. > > Perhaps, you can modify the (predict) rules for next years : if the end of Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a weekend), the next time shift will be the next weekend. > > > > >> A rule like this would ensure that Eid >> still uses the same time as Ramadan in every year, which is likely >> what people expect. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From milamberspace at gmail.com Sun May 31 18:57:26 2020 From: milamberspace at gmail.com (Milamber) Date: Sun, 31 May 2020 19:57:26 +0100 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> Message-ID: <4de35079-d19f-855d-55d7-7d93a3a291b0@gmail.com> On 5/31/20 6:25 PM, Matt Johnson-Pint wrote: > Forgive me if this is in any way ignorant, but why must the DST > transitions align so precisely with Ramadan? Because, during the Ramadan, the Muslims don't eat/drink from the sunrise to the sundown, so in Morocco with a GMT+1 timezone, the first lunch of the day will be near 08:30 pm (named 'Ftour' - Breakfast). So the people (and government) prefer switch back to GMT+0 to have the first lunch earlier during this month. > Would it not be sufficient if the dates for the time change were > predictable as long as the switch to GMT occurred sometime before the > start of Ramadan and the switch back to GMT+1 occurred sometime after? > Is there a political, social, or religious reason why they must be so > exactly aligned? > > -Matt > ------------------------------------------------------------------------ > *From:* tz on behalf of Milamber > > *Sent:* Sunday, May 31, 2020 7:03:50 AM > *To:* Florian Weimer ; Paul Eggert > *Cc:* Time zone mailing list > *Subject:* Re: [tz] FW: [Ext] The TZ Coordination > > > On 5/31/20 12:09 PM, Florian Weimer wrote: >> * Paul Eggert: >> >>> On 5/30/20 7:00 AM, Florian Weimer wrote: >>>>> Would this be a good opportunity to engage with the government of Morocco >>>>> to encourage them to give more warning? >>>> My understanding is that at present, they don't know themselves in >>>> advance. >>> Yes, I think you're right. >>> >>>> They would have to redefine the criteria to something based >>>> exclusively on astronomical calculations >>> That shouldn't be necessary, as they're using a conservative >>> approximation; that is, it's OK if their approximation is a bit off >>> because all they need to do is to bracket the actual Ramadan rather >>> than predict its Gregorian dates exactly. If they had an algorithm >>> they could publish it and we could use it. And it would be >>> technically feasible for them to have an algorithm; see the >>> Morocco-prediction code in the tzdb 'africa' file for an example >>> algorithm. >> It looks like the algorithm predicted correctly the data of Eid >> al-Fitr as 24 May, but the derivation of the end date from that is >> suspicious. I think it would make more sense if the time change does >> not happen on Eid itself. > > > In Morocco (where I live), the end of Ramadan (arabic month) is follow > by the Eid al-Fitr, and concretely it's 1 or 2 day off for the people > (with traditional visiting of family, big lunches/diners, etc.). So > for this year the astronomical calculations don't include the > following 2 day off in the calc. This 2 days have fall in a > Sunday/Monday, so it's not acceptable by people to have a time shift > during these 2 day off. > > Perhaps, you can modify the (predict) rules for next years : if the > end of Ramadan is a (probable) Friday or Saturday (and so the 2 day > off is on a weekend), the next time shift will be the next weekend. > > > > >> A rule like this would ensure that Eid >> still uses the same time as Ramadan in every year, which is likely >> what people expect. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSw.ab.ca Sun May 31 21:53:06 2020 From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis) Date: Sun, 31 May 2020 15:53:06 -0600 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <4de35079-d19f-855d-55d7-7d93a3a291b0@gmail.com> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> <4de35079-d19f-855d-55d7-7d93a3a291b0@gmail.com> Message-ID: <46097ac8-cb57-0b3c-7e87-ca87deb5b8e7@SystematicSw.ab.ca> There is also the Eid al-Fitr festival at the start of the next month Shawwal which may last from 1-5 days, during which for some reason they typically also do not want a time change, although I would think that an opportune period. On 2020-05-31 12:57, Milamber wrote: > On 5/31/20 6:25 PM, Matt Johnson-Pint wrote: >> Forgive me if this is in any way ignorant, but why must the DST transitions >> align so precisely with Ramadan?? > Because, during the Ramadan, the Muslims don't eat/drink from the sunrise to the > sundown, so in Morocco with a GMT+1 timezone, the first lunch of the day will be > near 08:30 pm (named 'Ftour' - Breakfast). So the people (and government) prefer > switch back to GMT+0 to have the first lunch earlier during this month. >> Would it not be sufficient if the dates for the time change were predictable >> as long as the switch to GMT occurred sometime before the start of Ramadan and >> the switch back to GMT+1 occurred sometime after?? Is there a political, >> social, or religious reason why they must be so exactly aligned? >> On Sunday, May 31, 2020 7:03:50 AM, Milamber wrote: >> On 5/31/20 12:09 PM, Florian Weimer wrote: >>>> On 5/30/20 7:00 AM, Florian Weimer wrote: >>>>>> Would this be a good opportunity to engage with the government of Morocco >>>>>> to encourage them to give more warning? >>>>> My understanding is that at present, they don't know themselves in >>>>> advance. >>>> Yes, I think you're right. >>>> >>>>> They would have to redefine the criteria to something based >>>>> exclusively on astronomical calculations >>>> That shouldn't be necessary, as they're using a conservative >>>> approximation; that is, it's OK if their approximation is a bit off >>>> because all they need to do is to bracket the actual Ramadan rather >>>> than predict its Gregorian dates exactly. If they had an algorithm >>>> they could publish it and we could use it. And it would be >>>> technically feasible for them to have an algorithm; see the >>>> Morocco-prediction code in the tzdb 'africa' file for an example >>>> algorithm. >>> It looks like the algorithm predicted correctly the data of Eid >>> al-Fitr as 24 May, but the derivation of the end date from that is >>> suspicious. I think it would make more sense if the time change does >>> not happen on Eid itself. >> >> >> In Morocco (where I live), the end of Ramadan (arabic month) is follow by the >> Eid al-Fitr, and concretely it's 1 or 2 day off for the people (with >> traditional visiting of family, big lunches/diners, etc.). So for this year >> the astronomical calculations don't include the following 2 day off in the >> calc. This 2 days have fall in a Sunday/Monday, so it's not acceptable by >> people to have a time shift during these 2 day off. >> >> Perhaps, you can modify the (predict) rules for next years : if the end of >> Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a >> weekend), the next time shift will be the next weekend. >> >> >> >> >>> A rule like this would ensure that Eid >>> still uses the same time as Ramadan in every year, which is likely >>> what people expect. >>> >> > -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] From eggert at cs.ucla.edu Sun May 31 22:23:27 2020 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 31 May 2020 15:23:27 -0700 Subject: [tz] FW: [Ext] The TZ Coordination In-Reply-To: <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> References: <93aead9b-a22c-9219-8355-72a24b9d9254@cs.ucla.edu> <20200528073409.GA72460@davros.org> <87y2p98qvb.fsf@mid.deneb.enyo.de> <3735a30a-2ce7-d05b-1876-aa961fe3bb74@cs.ucla.edu> <877dws744w.fsf@mid.deneb.enyo.de> <36e5d447-753c-6fda-f7a0-e922c0b67ef1@gmail.com> Message-ID: <39bf26a9-6143-5937-f890-2afcda21e059@cs.ucla.edu> On 5/31/20 7:03 AM, Milamber wrote: > Perhaps, you can modify the (predict) rules for next years : if the end of > Ramadan is a (probable) Friday or Saturday (and so the 2 day off is on a > weekend), the next time shift will be the next weekend. Thanks for the info. I installed the attached patch to change the predictions accordingly. Of course these predictions are somewhat fanciful if the Moroccan government itself doesn't know when the transitions will be. -------------- next part -------------- From e30fe68d4448a79d8ac95bf6ae81bb344328eb3c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 31 May 2020 15:17:11 -0700 Subject: [PATCH] Predict Morocco spring-forward after Eid al-Fitr MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit (Thanks to Milamber.) * NEWS: Mention this. * africa (Morocco): Change ?1+? to ?+ 2? in the commented-out code, and alter the prdicted rules accordingly for 2023-2085. --- NEWS | 7 +++++++ africa | 45 +++++++++++++++++++++++++++++---------------- 2 files changed, 36 insertions(+), 16 deletions(-) diff --git a/NEWS b/NEWS index ac491e1..8362dcc 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,13 @@ News for the tz database Unreleased, experimental changes + Changes to future timestamps + + Morocco's spring-forward after Ramadan is now predicted to occur + no sooner than two days after Ramadan, instead of one day. + (Thanks to Milamber.) The first altered prediction is for 2023, + now predicted to spring-forward on April 30 instead of April 23. + Changes to code The undocumented and ineffective tzsetwall function has been diff --git a/africa b/africa index 724744f..5d3beb0 100644 --- a/africa +++ b/africa @@ -875,17 +875,30 @@ Zone Indian/Mauritius 3:50:00 - LMT 1907 # Port Louis # https://maroc-diplomatique.net/maroc-le-retour-a-lheure-gmt-est-prevu-dimanche-prochain/ # http://aujourdhui.ma/actualite/gmt1-retour-a-lheure-normale-dimanche-prochain-1 # -# From Paul Eggert (2020-04-14): +# From Milamber (2020-05-31) +# In Morocco (where I live), the end of Ramadan (Arabic month) is followed by +# the Eid al-Fitr, and concretely it's 1 or 2 day offs for the people (with +# traditional visiting of family, big lunches/dinners, etc.). So for this +# year the astronomical calculations don't include the following 2 days off in +# the calc. These 2 days fall in a Sunday/Monday, so it's not acceptable by +# people to have a time shift during these 2 days off. Perhaps you can modify +# the (predicted) rules for next years: if the end of Ramadan is a (probable) +# Friday or Saturday (and so the 2 days off are on a weekend), the next time +# shift will be the next weekend. +# +# From Paul Eggert (2020-05-31): # For now, guess that in the future Morocco will fall back at 03:00 # the last Sunday before Ramadan, and spring forward at 02:00 the -# first Sunday after the day after Ramadan. To implement this, -# transition dates for 2021 through 2087 were determined by running -# the following program under GNU Emacs 26.3. -# (let ((islamic-year 1442)) +# first Sunday after two days after Ramadan. To implement this, +# transition dates and times for 2019 through 2087 were determined by +# running the following program under GNU Emacs 26.3. (This algorithm +# also produces the correct transition dates for 2016 through 2018, +# though the times differ due to Morocco's time zone change in 2018.) +# (let ((islamic-year 1440)) # (require 'cal-islam) # (while (< islamic-year 1511) # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year))) -# (b (1+ (calendar-islamic-to-absolute (list 10 1 islamic-year)))) +# (b (+ 2 (calendar-islamic-to-absolute (list 10 1 islamic-year)))) # (sunday 0)) # (while (/= sunday (mod (setq a (1- a)) 7))) # (while (/= sunday (mod b 7)) @@ -951,7 +964,7 @@ Rule Morocco 2021 only - May 16 2:00 0 - Rule Morocco 2022 only - Mar 27 3:00 -1:00 - Rule Morocco 2022 only - May 8 2:00 0 - Rule Morocco 2023 only - Mar 19 3:00 -1:00 - -Rule Morocco 2023 only - Apr 23 2:00 0 - +Rule Morocco 2023 only - Apr 30 2:00 0 - Rule Morocco 2024 only - Mar 10 3:00 -1:00 - Rule Morocco 2024 only - Apr 14 2:00 0 - Rule Morocco 2025 only - Feb 23 3:00 -1:00 - @@ -967,7 +980,7 @@ Rule Morocco 2029 only - Feb 18 2:00 0 - Rule Morocco 2029 only - Dec 30 3:00 -1:00 - Rule Morocco 2030 only - Feb 10 2:00 0 - Rule Morocco 2030 only - Dec 22 3:00 -1:00 - -Rule Morocco 2031 only - Jan 26 2:00 0 - +Rule Morocco 2031 only - Feb 2 2:00 0 - Rule Morocco 2031 only - Dec 14 3:00 -1:00 - Rule Morocco 2032 only - Jan 18 2:00 0 - Rule Morocco 2032 only - Nov 28 3:00 -1:00 - @@ -983,7 +996,7 @@ Rule Morocco 2036 only - Nov 23 2:00 0 - Rule Morocco 2037 only - Oct 4 3:00 -1:00 - Rule Morocco 2037 only - Nov 15 2:00 0 - Rule Morocco 2038 only - Sep 26 3:00 -1:00 - -Rule Morocco 2038 only - Oct 31 2:00 0 - +Rule Morocco 2038 only - Nov 7 2:00 0 - Rule Morocco 2039 only - Sep 18 3:00 -1:00 - Rule Morocco 2039 only - Oct 23 2:00 0 - Rule Morocco 2040 only - Sep 2 3:00 -1:00 - @@ -999,7 +1012,7 @@ Rule Morocco 2044 only - Aug 28 2:00 0 - Rule Morocco 2045 only - Jul 9 3:00 -1:00 - Rule Morocco 2045 only - Aug 20 2:00 0 - Rule Morocco 2046 only - Jul 1 3:00 -1:00 - -Rule Morocco 2046 only - Aug 5 2:00 0 - +Rule Morocco 2046 only - Aug 12 2:00 0 - Rule Morocco 2047 only - Jun 23 3:00 -1:00 - Rule Morocco 2047 only - Jul 28 2:00 0 - Rule Morocco 2048 only - Jun 7 3:00 -1:00 - @@ -1015,7 +1028,7 @@ Rule Morocco 2052 only - Jun 2 2:00 0 - Rule Morocco 2053 only - Apr 13 3:00 -1:00 - Rule Morocco 2053 only - May 25 2:00 0 - Rule Morocco 2054 only - Apr 5 3:00 -1:00 - -Rule Morocco 2054 only - May 10 2:00 0 - +Rule Morocco 2054 only - May 17 2:00 0 - Rule Morocco 2055 only - Mar 28 3:00 -1:00 - Rule Morocco 2055 only - May 2 2:00 0 - Rule Morocco 2056 only - Mar 12 3:00 -1:00 - @@ -1031,7 +1044,7 @@ Rule Morocco 2060 only - Mar 7 2:00 0 - Rule Morocco 2061 only - Jan 16 3:00 -1:00 - Rule Morocco 2061 only - Feb 27 2:00 0 - Rule Morocco 2062 only - Jan 8 3:00 -1:00 - -Rule Morocco 2062 only - Feb 12 2:00 0 - +Rule Morocco 2062 only - Feb 19 2:00 0 - Rule Morocco 2062 only - Dec 31 3:00 -1:00 - Rule Morocco 2063 only - Feb 4 2:00 0 - Rule Morocco 2063 only - Dec 16 3:00 -1:00 - @@ -1047,7 +1060,7 @@ Rule Morocco 2067 only - Dec 11 2:00 0 - Rule Morocco 2068 only - Oct 21 3:00 -1:00 - Rule Morocco 2068 only - Dec 2 2:00 0 - Rule Morocco 2069 only - Oct 13 3:00 -1:00 - -Rule Morocco 2069 only - Nov 17 2:00 0 - +Rule Morocco 2069 only - Nov 24 2:00 0 - Rule Morocco 2070 only - Oct 5 3:00 -1:00 - Rule Morocco 2070 only - Nov 9 2:00 0 - Rule Morocco 2071 only - Sep 20 3:00 -1:00 - @@ -1063,7 +1076,7 @@ Rule Morocco 2075 only - Sep 15 2:00 0 - Rule Morocco 2076 only - Jul 26 3:00 -1:00 - Rule Morocco 2076 only - Sep 6 2:00 0 - Rule Morocco 2077 only - Jul 18 3:00 -1:00 - -Rule Morocco 2077 only - Aug 22 2:00 0 - +Rule Morocco 2077 only - Aug 29 2:00 0 - Rule Morocco 2078 only - Jul 10 3:00 -1:00 - Rule Morocco 2078 only - Aug 14 2:00 0 - Rule Morocco 2079 only - Jun 25 3:00 -1:00 - @@ -1073,13 +1086,13 @@ Rule Morocco 2080 only - Jul 21 2:00 0 - Rule Morocco 2081 only - Jun 1 3:00 -1:00 - Rule Morocco 2081 only - Jul 13 2:00 0 - Rule Morocco 2082 only - May 24 3:00 -1:00 - -Rule Morocco 2082 only - Jun 28 2:00 0 - +Rule Morocco 2082 only - Jul 5 2:00 0 - Rule Morocco 2083 only - May 16 3:00 -1:00 - Rule Morocco 2083 only - Jun 20 2:00 0 - Rule Morocco 2084 only - Apr 30 3:00 -1:00 - Rule Morocco 2084 only - Jun 11 2:00 0 - Rule Morocco 2085 only - Apr 22 3:00 -1:00 - -Rule Morocco 2085 only - May 27 2:00 0 - +Rule Morocco 2085 only - Jun 3 2:00 0 - Rule Morocco 2086 only - Apr 14 3:00 -1:00 - Rule Morocco 2086 only - May 19 2:00 0 - Rule Morocco 2087 only - Mar 30 3:00 -1:00 - -- 2.25.4