From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by sourceware.org (Postfix) with ESMTPS id 55BFC3858D28 for ; Sat, 23 Mar 2024 16:38:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 55BFC3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSW.ab.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=SystematicSW.ab.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 55BFC3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=216.40.44.16 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711211929; cv=none; b=MrABw6b9n1mFKhp6JXrIBxUpIiJ2Bcg5TmnIEO2CCuJShxxcpjsyMlfWQL0mcr9XIIZyjzh1K7BEy8zAJ8udr7Kj3X1jXaT19QO8QHjNRM/a6dnqPXDeizXkzxxUUuvMcWpuzUCTtVjA6aDLnNX+aPOYDWjzdgoiLJOiFr86mz0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711211929; c=relaxed/simple; bh=Sga+/gwPKnTyhD+GNwfgHI+bc1gKKgZpvdaG7Bl4l5Q=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=QsGVlVDkWt8taL1Ab46t0L9ohvh5bCQRW4kyzlzCqMrzyLK9XIWmcmqrVlY/sT6uIThQzZcE1cnlpRYHlMX7392/RqEQqTUo6yqK/JMwoTP9Q+MeLfrS+55sLszbYMjDVuPfZLDST+OweUGwGimwvQyK5nv8kvl45EccVwf97Ck= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from omf08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E03DAC046E for ; Sat, 23 Mar 2024 16:38:45 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: Brian.Inglis@SystematicSW.ab.ca) by omf08.hostedemail.com (Postfix) with ESMTPA id 6357420026 for ; Sat, 23 Mar 2024 16:38:43 +0000 (UTC) Message-ID: Date: Sat, 23 Mar 2024 10:38:42 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: cygwin-apps@cygwin.com Subject: Re: [tz] Ubuntu drops old-style links Content-Language: en-CA To: cygwin-apps@cygwin.com References: <86ff5be5-ccae-4bc0-81af-46abc54e549d@systematicsw.ab.ca> <14e3ae03-bacf-4946-badc-19de78d9eece@SystematicSW.ab.ca> <88dd91a6-5fde-49a7-a0a5-afd5e9b01e15@SystematicSW.ab.ca> From: Brian Inglis Organization: Systematic Software In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 6357420026 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Stat-Signature: grxoauurixpkox83sdw9uhr9wk4duo65 X-Rspamd-Server: rspamout04 X-Session-Marker: 427269616E2E496E676C69734053797374656D6174696353572E61622E6361 X-Session-ID: U2FsdGVkX18qhG6b2ykmSqvpclbNQWXmtLtZtCE1uiQ= X-HE-Tag: 1711211923-200591 X-HE-Meta: U2FsdGVkX18PQIj+HIkbHpFseNG+yfwGkV12K5MvhM6/RxFZxieYX0HnvjfFggeOuynlvDSUnwBcb8JTkCuw7VGDzaGHrezLaICYksKXuY0BHsLw6jsiKlDCgCtVGBFZxaO4PSEXEc1vLE6Et1lBJawRhNORJIom5vwUPZ5dGyS6LdMmO/j5MhWqmh6zqRneXJ/52BcWMMxLZjtARTK3eq/xIN10eFd2P2Yxvl6ECefCGea/FM7x5qWYmqT7vDKwML2T6SDMqQaaACzA3itW6UijIJIpbP2fRg5KKoAbH2lH5MC+t92dK8k41ah5fR9QiPYgrf7U9l9LZ/UZKACw5uUMqylV4GbysyYWl53pwsQ0RPy1eQRbij0kuF5w81IUrercAXg/47/xDWqyKmaBgCHkjLinCCfIO48pMAtzqfI7DiB+XiLDFWxsva4luHpceP5+rxkgdTUddgM1rZPOHFkB5VPTuay37vkap/In+Uj/9AgacorsRJAzS77LgmuJZ0H84JvNC0ZLZaw4mOzpKK1lj5vXh5DfLg58c+HqxVI4B5p3Rc3wDAdh0vPN0Yh7GIvq9CmmG+2VSPCzVtsWA0I1V1Ea1I1fMgN+Iz+dUZzQNwaV2QNxnbT1hZ0wIApe X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-03-23 03:54, Corinna Vinschen via Cygwin-apps wrote: > On Mar 22 10:02, Brian Inglis via Cygwin-apps wrote: >> On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote: >>> We're generating the conversion from Windows to POSIX timezone via >>> the conversion table from unicode.org: >>> >>> https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/tzmap-from-unicode.org >>> >>> Plus a few (7, actually) mappings the Unicode consortium missed in >>> the list (or maybe they are available in the meantime, needs checking). >>> This is the minimum list of timezone info we need in the tzdata DB. >> >> I generated tzmap.h and generated differences since the last update cldr ~40. >> I also searched in the latest for matches for each field attached as first. >> >> I do not know if they will be of help as I see you have already looked at tzmap. >> >> It looks as if the match might better prioritize country code over Windows label. > > Which match? I'm not sure what you're trying to tell me. > > Basically, we want to generate a POSIX timezone from the current user's > Windows timezone. This boils down to four questions: > > - Is the creation of tzmap.h from unicode.org via the > tzmap-from-unicode.org script the right thing to do or not? > > - If it's the wrong thing to do, what other source do you propose and do > you have a script to perform the conversion from this source to a > valid tzmap.h file? > > - Otherwise, is the current tzmap-from-unicode.org right or wrong in > adding these old extra timezone/territory settings, or is even > some combination missing? > > - If so, would you mind to send a patch to fix tzmap-from-unicode.org > accordingly? I have a decent background in tzdata, but little in Windows or CLDR, although at least information from the latter can be extracted from GitHub. It looks to me that tzset.c prioritizes the Windows label over the country, and it may be a better match prioritizing the country over the label, if the country is not 001/"", nor ZZ, which are the generic entries. It also is not clear what tzset should do when tzmap has a list of zones to choose from, for example: { L"Mountain Standard Time", L"CA", L"America/Edmonton America/Cambridge_Bay America/Inuvik" }, { L"Mountain Standard Time", L"US", L"America/Denver America/Boise" }, { L"US Mountain Standard Time", L"CA", L"America/Creston America/Dawson_Creek America/Fort_Nelson" }, it currently just prints the first, but perhaps it should print all relevant entries and the caller should handle the alternatives? There also seem to be issues with CLDR data: https://postgrespro.com/list/thread-id/2571399 not to mention the delays in updating Windows and CLDR data: 2021 Samoa DST change in 2024 March/April Windows updates https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/interim-guidance-for-samoa-dst-changes-2021/ba-p/4048965 Intermittent updates from tzdata and Windows https://github.com/unicode-org/cldr/commits/main/common/supplemental/windowsZones.xml plus they no longer seem to be updating the tzdata version in that file since 2021a. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry