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
