On 2024-03-23 10:38, Brian Inglis via Cygwin-apps wrote:
> 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.

 From the point of view of tzdata, given most zones are required in tzmap for 
tzset to use, we can not reduce much there: see tzmap summary attached.

So the only significant reductions we can make by splitting are with the right 
and posix subtrees, perhaps in two or a single extra package: see zi summary.

-- 
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