Re: [tz] Ubuntu drops old-style links - tzdata split test package

[Brian Inglis via Cygwin-apps]

On 2024-03-28 04:13, Corinna Vinschen via Cygwin-apps wrote:

On Mar 28 02:25, Brian Inglis via Cygwin-apps wrote:

I have released and announced a test package of tzdata 2024a-2 split into
three install packages: base tzdata, optional tzdata-right, and redundant
tzdata-posix, each containing all the legacy zones so that tzset continues
to work as before.

I could not reduce the base installed zones by many, because most were used
by tzset, but I did drop a couple of large zone source files, produced by
the build, that were previously included to allow users to see the source
zones, rules, and links in effect, saving ~1MB, and dropping the overall
default base installed file sizes by ~80% to ~20% of current, and download
tar size by ~60% to ~40%; for all zones aggregate total installed file sizes
are dropped by ~35% to ~65%, and download tar sizes by ~30% to ~70% of
current:

install   tar   tzdata
  721KB  172KB   base
  984KB   78KB   right
  669KB   74KB   posix
 1367KB  444KB   source
 3667KB  452KB   current

Please check out the announcement, cygwin list echo, source and install
package summary web pages, cygport changes, setup entries, scallywag builds,
and let me know if there is anything you see that could benefit from
improvement.


Fedora Rawhide is not following this scheme.  For F40 and F41 it still
prepares single tzdata packages.  FWIW, OpenSuSE also only comes with a
single timezone package in Tumbleweed.

Comparing the Cygwin and the Fedora package, the only differences are:

  Cygwin comes with two files not in the Fedora package:

/usr/share/zoneinfo/rearguard.zi


Source tzdata zones, rules, links,
- driven by tzdata make symbol settings,
- in legacy tzdata format supported by newlib-cygwin libc,
- generated as base zic input source to provide all the legacy zones used by 
tzset, and
- allows users to view the tzdata rules in effect for their zone(s) of interest; 
- dropped in the test package,
- along with tzdata.zi, which is the abbreviated generated source file used by 
zic to build the zoneinfo subtrees,

- driven also by zic parameters for each subtree, almost identical to Fedora:

https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec

- except they still use the deprecated obsolete yearistype shell script with 
zic, supporting deprecated obsolete US presidential and odd/even year rules.


Once we know that the libc code is updated to support the new zic output data 
ranges, we could transition to main or vanguard source formats and slim output 
formats, as long as the required tzset zone files are still generated in those 
formats.


This is the same as provided in RHEL, see notes on tzdata-2018e in:

https://access.redhat.com/articles/1187353

and Fedora

https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec


/usr/share/zoneinfo/zonenow.tab


Compare the RH notes, Fedora tzdata.spec embedded changelog, cygport git log, 
and cygwin-announce upstream release notes, for similar information.


New minimal tzdata zone selection which builds *only* the minimal zones required 
to provide current time around the world, but may require selection of a 
different zone; supported by make and in /bin/tzselect by undocumented -t 
zonetabtype option.



  Fedora comes with two files not in the Cygwin package:

/usr/share/zoneinfo/leap-seconds.list


IERS/NIST upstream NTP leap-seconds.list PD distribution file: we provide only 
the tzdata format leapseconds file in /usr/share/zoneinfo/, generated from the 
NTP list, instead; that way we do not need to specify another licence, which 
appears not to be stated in:


https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec


/usr/share/zoneinfo/posixrules


Deprecated obsolete legacy rules: see tzdata-2020b notes discussing patch to 
provide this in:


https://access.redhat.com/articles/1187353

and 2020d-3 notes in:

https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec


That's all.  And given that space is not one of the major limiting
factors anymore...

   cyg$ du -sh /usr/share/zoneinfo
   6.6M/usr/share/zoneinfo

   fed$ du -sh /usr/share/zoneinfo
   4.6M /usr/share/zoneinfo

...I do wonder a bit if this split is really necessary after all.


It cuts the base install (--apparent) size by ~3MB to 721KB, time and load for 
this by a factor of 5, for mirrors, CI, and other repetitive container and 
packaged build server installs like ansible, docker, scallywag, etc.


Few users are likely to use any of the right or redundant posix subtrees, unless 
they have astrophysics or time/frequency physics interests.


Astronomers and astrologers, CLDR, ICU, and Cygwin Windows tzmap are better 
served by providing all the legacy zones.


FYI:

The primary maintainer of tzcode/tzdata is an Ubuntu user, and keen to drop as 
much of the legacy and what he considers as questionable history as possible, 
despite a project data fork to

Re: [tz] Ubuntu drops old-style links - tzdata split test package

[Corinna Vinschen via Cygwin-apps]

On Mar 28 02:25, Brian Inglis via Cygwin-apps wrote:
> I have released and announced a test package of tzdata 2024a-2 split into
> three install packages: base tzdata, optional tzdata-right, and redundant
> tzdata-posix, each containing all the legacy zones so that tzset continues
> to work as before.
> 
> I could not reduce the base installed zones by many, because most were used
> by tzset, but I did drop a couple of large zone source files, produced by
> the build, that were previously included to allow users to see the source
> zones, rules, and links in effect, saving ~1MB, and dropping the overall
> default base installed file sizes by ~80% to ~20% of current, and download
> tar size by ~60% to ~40%; for all zones aggregate total installed file sizes
> are dropped by ~35% to ~65%, and download tar sizes by ~30% to ~70% of
> current:
> 
> install   tar   tzdata
>  721KB  172KB   base
>  984KB   78KB   right
>  669KB   74KB   posix
> 1367KB  444KB   source
> 3667KB  452KB   current
> 
> Please check out the announcement, cygwin list echo, source and install
> package summary web pages, cygport changes, setup entries, scallywag builds,
> and let me know if there is anything you see that could benefit from
> improvement.

Fedora Rawhide is not following this scheme.  For F40 and F41 it still
prepares single tzdata packages.  FWIW, OpenSuSE also only comes with a
single timezone package in Tumbleweed.

Comparing the Cygwin and the Fedora package, the only differences are:

 Cygwin comes with two files not in the Fedora package:

   /usr/share/zoneinfo/rearguard.zi
   /usr/share/zoneinfo/zonenow.tab

 Fedora comes with two files not in the Cygwin package:

   /usr/share/zoneinfo/leap-seconds.list
   /usr/share/zoneinfo/posixrules

That's all.  And given that space is not one of the major limiting
factors anymore...

  cyg$ du -sh /usr/share/zoneinfo
  6.6M/usr/share/zoneinfo

  fed$ du -sh /usr/share/zoneinfo
  4.6M  /usr/share/zoneinfo

...I do wonder a bit if this split is really necessary after all.


Corinna

Re: [tz] Ubuntu drops old-style links - tzdata split test package

[Brian Inglis via Cygwin-apps]

On 2024-03-23 15:11, Corinna Vinschen via Cygwin-apps wrote:

On Mar 23 10:38, Brian Inglis via Cygwin-apps wrote:

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.


The Windows timezone is the relevant setting in the first place becasue
that's what indicvates the actual local time *as the user chose*.
The territory should only be a secondary hint to choose the right
POSIX entry.

For instance, I know people always using UTC, independently of their
territory setting. If the territory rules, this user choice would be
broken in Cygwin.


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?


tzset is called from the shell default profile.  It has to use exactly
one, valid entry, so time works as desired without forcing interactivity.

If the user doesn't like it, the user can always override tzset's choice
in her own profile.


I have released and announced a test package of tzdata 2024a-2 split into three 
install packages: base tzdata, optional tzdata-right, and redundant 
tzdata-posix, each containing all the legacy zones so that tzset continues to 
work as before.


I could not reduce the base installed zones by many, because most were used by 
tzset, but I did drop a couple of large zone source files, produced by the 
build, that were previously included to allow users to see the source zones, 
rules, and links in effect, saving ~1MB, and dropping the overall default base 
installed file sizes by ~80% to ~20% of current, and download tar size by ~60% 
to ~40%; for all zones aggregate total installed file sizes are dropped by ~35% 
to ~65%, and download tar sizes by ~30% to ~70% of current:


install   tar   tzdata
 721KB  172KB   base
 984KB   78KB   right
 669KB   74KB   posix
1367KB  444KB   source
3667KB  452KB   current

Please check out the announcement, cygwin list echo, source and install package 
summary web pages, cygport changes, setup entries, scallywag builds, and let me 
know if there is anything you see that could benefit from improvement.


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

Re: [tz] Ubuntu drops old-style links

[Corinna Vinschen via Cygwin-apps]

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

The Windows timezone is the relevant setting in the first place becasue
that's what indicvates the actual local time *as the user chose*.
The territory should only be a secondary hint to choose the right
POSIX entry.

For instance, I know people always using UTC, independently of their
territory setting. If the territory rules, this user choice would be
broken in Cygwin.

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

tzset is called from the shell default profile.  It has to use exactly
one, valid entry, so time works as desired without forcing interactivity.

If the user doesn't like it, the user can always override tzset's choice
in her own profile.


Corinna

Re: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

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érytzmap total extra
pri 1  87/ 91  4 zones src zonenow.tab
pri 2 210/221 11 zones src zone1970.tab 
pri 3 101/132 31 zones src backzone 
pri 4  19/113 94 zones src backward 
pri 5  32/ 41  9 zones src files 
total 449/598149 zones 

1.8M/usr/share/zoneinfo/posix
2.4M/usr/share/zoneinfo/right
2.8M/usr/share/zoneinfo/
6.9Mtotal

Re: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

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

Re: [tz] Ubuntu drops old-style links

[Corinna Vinschen via Cygwin-apps]

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?


Corinna

Re: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-22 10:02, Brian Inglis via Cygwin-apps wrote:

On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote:

On Mar 20 14:59, Brian Inglis via Cygwin-apps wrote:

On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:

On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:

I just learned that Ubuntu Noble (24.04) decided to intentionally
split the tzdata package.  Old-style links such as US/Eastern are no
longer included by default, but are available in the tzdata-legacy
package instead.

Just thought I'd share.  I wonder if other distributions / platforms
/ libraries will follow suit.  What do y'all think?

See:





I've been looking at that to reduce Cygwin CI and embedded build server
setup overhead by limiting base install data to:

- only the zones in zonenow.tab;
- optionally those in zone1970.tab not in zonenow.tab;
- additionally those in zone.tab in backward, and/or backzone;
- possibly those not in zone.tab, only in backward, and/or backzone;
- additions those in posix subtree, or right subtree.


As tzdata maintainer, I would like to discuss on this list first, to take
advantage of a wide variety of experience in different environments with
different practices and requirements, before making more definite proposals
on the public list.

Please see the attached log for prioritized subsets of tzdata for consideration:
[...]
What would the impact on tzset conversion from Windows to Olson tzdb be?
We would probably have to add all of these in to any minimal install.
I think I looked at that somewhere, sometime, not too long ago.


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.


The attached log shows the 449 time zones required to support the latest tzmap.

Counts of each priority compared to all zones are:

pri 1  87/ 91 zones src zonenow.tab
pri 2 210/221 zones src zone1970.tab
pri 3 101/132 zones src backzone
pri 4  19/113 zones src backward
pri 5  32/ 41 zones src files

--
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éryAfrica/Abidjan  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Algiers  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Cairo1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Casablanca   1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Johannesburg 1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Lagos1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Maputo   1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Nairobi  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Tripoli  1   zonenow.tab zone1970.tab
africa  zone.tab
America/Adak1   zonenow.tab zone1970.tab
northamericazone.tab
America/Anchorage   1   zonenow.tab zone1970.tab
northamericazone.tab
America/Asuncion1   zonenow.tab zone1970.tab
southamericazone.tab
America/Caracas 1   zonenow.tab zone1970.tab
southamericazone.tab
America/Chicago 1   zonenow.tab zone1970.tab
no

Re: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-22 10:02, Brian Inglis via Cygwin-apps wrote:

On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote:

On Mar 20 14:59, Brian Inglis via Cygwin-apps wrote:

On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:

On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:

I just learned that Ubuntu Noble (24.04) decided to intentionally
split the tzdata package.  Old-style links such as US/Eastern are no
longer included by default, but are available in the tzdata-legacy
package instead.

Just thought I'd share.  I wonder if other distributions / platforms
/ libraries will follow suit.  What do y'all think?

See:





I've been looking at that to reduce Cygwin CI and embedded build server
setup overhead by limiting base install data to:

- only the zones in zonenow.tab;
- optionally those in zone1970.tab not in zonenow.tab;
- additionally those in zone.tab in backward, and/or backzone;
- possibly those not in zone.tab, only in backward, and/or backzone;
- additions those in posix subtree, or right subtree.


As tzdata maintainer, I would like to discuss on this list first, to take
advantage of a wide variety of experience in different environments with
different practices and requirements, before making more definite proposals
on the public list.

Please see the attached log for prioritized subsets of tzdata for consideration:
[...]
What would the impact on tzset conversion from Windows to Olson tzdb be?
We would probably have to add all of these in to any minimal install.
I think I looked at that somewhere, sometime, not too long ago.


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.


The attached log shows the 449 time zones required to support the latest tzmap.

--
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
Africa/Abidjan  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Algiers  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Cairo1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Casablanca   1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Johannesburg 1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Lagos1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Maputo   1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Nairobi  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Tripoli  1   zonenow.tab zone1970.tab
africa  zone.tab
America/Adak1   zonenow.tab zone1970.tab
northamericazone.tab
America/Anchorage   1   zonenow.tab zone1970.tab
northamericazone.tab
America/Asuncion1   zonenow.tab zone1970.tab
southamericazone.tab
America/Caracas 1   zonenow.tab zone1970.tab
southamericazone.tab
America/Chicago 1   zonenow.tab zone1970.tab
northamericazone.tab
America/Denver  1   zonenow.tab zone1970.tab
northamericazone.tab
America/Halifax 1   zonenow.tab 

Re: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote:

On Mar 20 14:59, Brian Inglis via Cygwin-apps wrote:

On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:

On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:

I just learned that Ubuntu Noble (24.04) decided to intentionally
split the tzdata package.  Old-style links such as US/Eastern are no
longer included by default, but are available in the tzdata-legacy
package instead.

Just thought I'd share.  I wonder if other distributions / platforms
/ libraries will follow suit.  What do y'all think?

See:





I've been looking at that to reduce Cygwin CI and embedded build server
setup overhead by limiting base install data to:

- only the zones in zonenow.tab;
- optionally those in zone1970.tab not in zonenow.tab;
- additionally those in zone.tab in backward, and/or backzone;
- possibly those not in zone.tab, only in backward, and/or backzone;
- additions those in posix subtree, or right subtree.


As tzdata maintainer, I would like to discuss on this list first, to take
advantage of a wide variety of experience in different environments with
different practices and requirements, before making more definite proposals
on the public list.

Please see the attached log for prioritized subsets of tzdata for consideration:
[...]
What would the impact on tzset conversion from Windows to Olson tzdb be?
We would probably have to add all of these in to any minimal install.
I think I looked at that somewhere, sometime, not too long ago.


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.

--
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* additional zones - some may now be unnecessary as of latest CLDR 45-a3
  current zones are matched by Windows label, country code, zone id

* { L"E. Europe Standard Time", L"", L"Asia/Nicosia" },
* { L"E. Europe Standard Time", L"CY", L"Asia/Nicosia" },
  { L"E. Europe Standard Time", L"", L"Europe/Chisinau" },
  { L"E. Europe Standard Time", L"MD", L"Europe/Chisinau" },
  { L"GTB Standard Time", L"CY", L"Asia/Nicosia Asia/Famagusta" },

* { L"Eastern Standard Time", L"TC", L"America/Grand_Turk" },
  { L"Eastern Standard Time", L"", L"America/New_York" },
  { L"Eastern Standard Time", L"BS", L"America/Nassau" },
  { L"Eastern Standard Time", L"CA", L"America/Toronto America/Iqaluit" },
  { L"Eastern Standard Time", L"US", L"America/New_York America/Detroit 
America/Indiana/Petersburg America/Indiana/Vincennes America/Indiana/Winamac 
America/Kentucky/Monticello America/Louisville" },
  { L"Eastern Standard Time", L"ZZ", L"EST5EDT" },
  { L"Turks And Caicos Standard Time", L"TC", L"America/Grand_Turk" },
  { L"Turks And Caicos Standard Time", L"", L"America/Grand_Turk" },

* { L"Egypt Standard Time", L"PS", L"Asia/Gaza Asia/Hebron" },
  { L"Egypt Standard Time", L"", L"Africa/Cairo" },
  { L"Egypt Standard Time", L"EG", L"Africa/Cairo" },
  { L"West Bank Standard Time", L"", L"Asia/Hebron" },
  { L"West Bank Standard Time", L"PS", L"Asia/Hebron Asia/Gaza" },

* { L"Greenwich Standard Time", L"EH", L"Africa/El_Aaiun" },
  { L"Greenwich Standard Time", L"", L"Atlantic/Reykjavik" },
  { L"Greenwich Standard Time", L"BF", L"Africa/Ouagadougou" },
  { L"Greenwich Standard Time", L"CI", L"Africa/Abidjan" },
  { L"Greenwich Standard Time", L"GH", L"Africa/Accra" },
  { L"Greenwich Standard Time", L"GL", L"America/Danmarkshavn" },
  { L"Greenwich Standard Time", L"GM", L"Africa/Banjul" },
  { L"Greenwich Standard Time", L"GN", L"Africa/Conakry" },
  { L"Greenwich Standard Time", L"GW", L"Africa/Bissau" },
  { L"Greenwich Standard Time", L"IS", L"Atlantic/Reykjavik" },
  { L"Greenwich Standard Time", L"LR", L"Africa/Monrovia" },
  { L"Greenwich Standard Time", L"ML", L"Africa/Bamako" },
  { L"Greenwich Standard Time", L"MR", L"Africa/Nouakchott" },
  { L"Greenwich Standard Time", L"SH", L"Atlantic/St_Helena" },
  { L"Greenwich Standard Tim

Re: [tz] Ubuntu drops old-style links

[Corinna Vinschen via Cygwin-apps]

On Mar 20 14:59, Brian Inglis via Cygwin-apps wrote:
> On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:
> > On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:
> > > I just learned that Ubuntu Noble (24.04) decided to intentionally
> > > split the tzdata package.  Old-style links such as US/Eastern are no
> > > longer included by default, but are available in the tzdata-legacy
> > > package instead.
> > > 
> > > Just thought I'd share.  I wonder if other distributions / platforms
> > > / libraries will follow suit.  What do y'all think?
> > > 
> > > See:
> > > 
> > > 
> 
> > I've been looking at that to reduce Cygwin CI and embedded build server
> > setup overhead by limiting base install data to:
> > 
> > - only the zones in zonenow.tab;
> > - optionally those in zone1970.tab not in zonenow.tab;
> > - additionally those in zone.tab in backward, and/or backzone;
> > - possibly those not in zone.tab, only in backward, and/or backzone;
> > - additions those in posix subtree, or right subtree.
> 
> As tzdata maintainer, I would like to discuss on this list first, to take
> advantage of a wide variety of experience in different environments with
> different practices and requirements, before making more definite proposals
> on the public list.
> 
> Please see the attached log for prioritized subsets of tzdata for 
> consideration:
> [...]
> What would the impact on tzset conversion from Windows to Olson tzdb be?
> We would probably have to add all of these in to any minimal install.
> I think I looked at that somewhere, sometime, not too long ago.

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.

Corinna

Fwd: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:

On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:
I just learned that Ubuntu Noble (24.04) decided to intentionally split the 
tzdata package.  Old-style links such as US/Eastern are no longer included by 
default, but are available in the tzdata-legacy package instead.


Just thought I'd share.  I wonder if other distributions / platforms / 
libraries will follow suit.  What do y'all think?


See:




I've been looking at that to reduce Cygwin CI and embedded build server setup 
overhead by limiting base install data to:


- only the zones in zonenow.tab;
- optionally those in zone1970.tab not in zonenow.tab;
- additionally those in zone.tab in backward, and/or backzone;
- possibly those not in zone.tab, only in backward, and/or backzone;
- additions those in posix subtree, or right subtree.


As tzdata maintainer, I would like to discuss on this list first, to take 
advantage of a wide variety of experience in different environments with 
different practices and requirements, before making more definite proposals on 
the public list.


Please see the attached log for prioritized subsets of tzdata for consideration:

#1 minimal zones required to set the time as it is used around the globe, which 
may require using a different zone id (name) than before, and will be correct 
from release onwards, but possibly not exactly the same historically


#2 extra zones whose clocks have agreed since 1970 and provides correct 
historical times for the zone based on those locations from 1970 onwards


#3 zones which have more, but possibly questionable, historical data

#4 backward compatibility links to other zones, like legacy country based 
directories or regions, or because of renames, splits, data proved uncertain, 
never really correct, never used in the region, was the same as surrounding or 
adjacent regions, or was part of a different country


#5 legacy and historical zone ids

Counts of each are:

pri 1  91 zones src zonenow.tab
pri 2 221 zones src zone1970.tab
pri 3 132 zones src backzone
pri 4 113 zones src backward
pri 5  41 zones src files

There are also the subtrees for posix, which duplicates the base data, in 
contrast to the right subtree which has the same zone names, but provides 
TAI-10s time_t counting leapseconds (currently UTC+27s) ignoring 86400s/day.


The balance is between a proliferation of packages and reasonable selections of 
data, so discussions will be pursued, opinions solicited, possibly debated.


The first package split I propose is tzdata-right, which will include both the 
right and posix subtrees, as few outside the physics communities may need this, 
and we don't know if anyone uses it on Cygwin: yet!


Next for consideration is where the legacy and historical #5 ids fit?
Should they be split into a separate package, or included in a package for 
servers that possibly still use original zones, or require specific GMT offsets, 
like ships at sea?


Then we should look at what to do with the backzone #3 and backward #4 zones 
that offer more historical data, plus backward compatability ids and links, 
which may be useful to the astrological community, and on user desktops.
The backward links could be replaced by instructions taht say if you are using 
link id, use zone id instead.


The zones in #2 allow recent history to be followed and a large number of zones 
that most desktop users are likely to expect to have available.
For me, this includes my local America/Edmonton zone which tracks provincial 
variations in DST observance over the last half century before DST was more 
standardized.


The zones in #1 are limited but reduce minimum install footprint for CI and 
servers that may use few zones other than the built in UTC default.

For me, that means I would have to select America/Denver to get MT with NA DST.
The practice would be similar in Europe: most Europeans would have to select 
Europe/Berlin, as that is the most populous city using that time zone.
Would this be a good place to add #5 in case legacy zone ids are used on server 
builds?


What would the impact on tzset conversion from Windows to Olson tzdb be?
We would probably have to add all of these in to any minimal install.
I think I looked at that somewhere, sometime, not too long ago.

All questions, comments, and suggestions will be greatfully received and 
responded to.


--
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éryAfrica/Abidjan  1   zonenow.tab zone1970.tab