timezone-2025b-160000.2.2

- Update to 2025b:
  * New zone for Aysén Region in Chile (America/Coyhaique) which
    moves from -04/-03 to -03

- Update to 2025a:
  * Paraguay adopts permanent -03 starting spring 2024
  * Improve pre-1991 data for the Philippines
  * Etc/Unknown is now reserved

- Update to 2024b:
  * Improve historical data for Mexico, Mongolia, and Portugal.
  * System V names are now obsolescent.
  * The main data form now uses %z.
  * The code now conforms to RFC 8536 for early timestamps.
  * Support POSIX.1-2024, which removes asctime_r and ctime_r.
  * Assume POSIX.2-1992 or later for shell scripts.
  * SUPPORT_C89 now defaults to 1.

- Split tzselect script into a subpackage to prevent awk getting into minimal
  containers and recommend tzselect by the main package
  Fixes bsc#1230054

- Unify SLE-15-SP6 and Factory packages (PED#8158).
  This is still related to bsc#1213470. We're applying this fix for
  SLE-15-SP6 too.  This changelog entry is meant to bring over the SLE
  information, so the same package can be used for both code streams.
- This patch has long been removed on Factory but was never mentioned
  explicitly, it was related to ticket bsc#1202310, a minor update to
  reflect Chile's DST change back in 2022.
  * bsc1202310.patch

- Use /bin/sh for tzselect. Used to require bash for the 'select'
  builtin but has a fallback meanwhile so no need for explicit bash
  anymore.

- Drop the timezone-java (bsc#1213470).
  After thorough consideration of possible problems that arise from
  having a timezone package specifically for the Java ecosystem,
  Fridrich Strba and I have decided to drop the package altogether.
  Doing so means the JDK will use its built-in timezone data that is
  updated quarterly, when refreshed JDK versions are released.
  While this does mean there could be situations where there is a bit
  of a mismatch between the 'timezone' package's data, and the data
  that is used by JDK, in practice the difference will be minimal and
  short-lived.
  So we've established this to be the best course of action.
- Remove _multibuild, not longer required.

- Update to 2024a:
  * Kazakhstan unifies on UTC+5 beginning 2024-03-01
  * Palestine springs forward a week later after Ramadan
  * zic no longer pretends to support indefinite-past DST
  * localtime no longer mishandles Ciudad Juárez in 2422

- update to 2023d:
  * Ittoqqortoormiit, Greenland changes time zones on
    2024-03-31.
  * Vostok, Antarctica changed time zones on 2023-12-18.
  * Casey, Antarctica changed time zones five times since
    2020.
  * Code and data fixes for Palestine timestamps starting in
    2072.
  * A new data file zonenow.tab for timestamps starting now.
  * Fix predictions for DST transitions in Palestine in
    2072-2075, correcting a typo introduced in 2023a.
  * Vostok, Antarctica changed to +05 on 2023-12-18.  It had
    been at +07 (not +06) for years.
  * Change data for Casey, Antarctica to agree with
    timeanddate.com, by adding five time zone changes since 2020.
    Casey is now at +08 instead of +11.
  * Much of Greenland, represented by America/Nuuk, changed
    its standard time from -03 to -02 on 2023-03-25, not on
    2023-10-28.
  * localtime.c no longer mishandles TZif files that contain
    a single transition into a DST regime.  Previously,
    it incorrectly assumed DST was in effect before the transition
    too.
  * tzselect no longer creates temporary files.
  * tzselect no longer mishandles the following:
  * Spaces and most other special characters in BUGEMAIL,
    PACKAGE, TZDIR, and VERSION.
  * TZ strings when using mawk 1.4.3, which mishandles
    regular expressions of the form /X{2,}/.
  * ISO 6709 coordinates when using an awk that lacks the
    GNU extension of newlines in -v option-arguments.
  * Non UTF-8 locales when using an iconv command that
    lacks the GNU //TRANSLIT extension.
  * zic no longer mishandles data for Palestine after the
    year 2075.

- timezone update 2023c:
  * Reverts changes for 2023 Lebanon DST change to 2023a data