public inbox for cygwin-announce@cygwin.com
 help / color / mirror / Atom feed
From: "Cygwin tzcode/tzdata Maintainer" <Brian.Inglis@SystematicSW.ab.ca>
To: "Cygwin Announcements" <cygwin-announce@cygwin.com>
Subject: Updated: tzcode, tzdata 2024a
Date: Sat, 03 Feb 2024 12:46:22 -0700	[thread overview]
Message-ID: <20240203124622.40160-1-Brian.Inglis@SystematicSW.ab.ca> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3196 bytes --]

The following packages have been upgraded in the Cygwin distribution:

* tzcode	2024a
* tzdata	2024a

The Time Zone Database (often called tz, tzdb, or zoneinfo) contains
data that represents the history of local time for many locations around
the world, and supports conversion of UTC time to local time at those
locations to allow display of those local times. It is updated
periodically to reflect changes made by political bodies to summer
daylight saving time rules, UTC offsets, and time zone boundaries.
The tzcode package provides the tzselect, zdump, and zic utilities.

For more information, see the project home page:

	https://www.iana.org/time-zones

For more details on changes, see the announcement or below:

	https://mm.icann.org/pipermail/tz-announce/2024-February/000081.html


2024a	2024-02-01

Briefly:
- 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.

Changes to future timestamps

- Kazakhstan unifies on UTC+5. This affects Asia/Almaty and
  Asia/Qostanay which together represent the eastern portion of the
  country that will transition from UTC+6 on 2024-03-01 at 00:00 to join
  the western portion.

- Palestine springs forward a week later than previously predicted in
  2024 and 2025. Change spring-forward predictions to the second
  Saturday after Ramadan, not the first; this also affects other
  predictions starting in 2039.

Changes to past timestamps

- Asia/Ho_Chi_Minh's 1955-07-01 transition occurred at 01:00 not 00:00.

- From 1947 through 1949, Toronto's transitions occurred at 02:00 not
  00:00.

- In 1911 Miquelon adopted standard time on June 15, not May 15.

Changes to code

- The FROM and TO columns of Rule lines can no longer be "minimum" or an
  abbreviation of "minimum", because TZif files do not support DST rules
  that extend into the indefinite past - although these rules were
  supported when TZif files had only 32-bit data, this stopped working
  when 64-bit TZif files were introduced in 1995. This should not be a
  problem for realistic data, since DST was first used in the 20th
  century. As a transition aid, FROM columns like "minimum" are now
  diagnosed and then treated as if they were the year 1900; this should
  suffice for TZif files on old systems with only 32-bit time_t, and it
  is more compatible with bugs in 2023c-and-earlier localtime.c.

- localtime and related functions no longer mishandle some timestamps
  that occur about 400 years after a switch to a time zone with a DST
  schedule. In 2023d data this problem was visible for some timestamps
  in November 2422, November 2822, etc. in America/Ciudad_Juarez.

- strftime %s now uses tm_gmtoff if available.

Changes to build procedure

- The leap-seconds.list file is now copied from the IERS instead of from
  its downstream counterpart at NIST, as the IERS version is now in the
  public domain too and tends to be more up-to-date.

Changes to documentation

- The strftime man page documents which struct tm members affect which
  conversion specs, and that tzset is called.


                 reply	other threads:[~2024-02-03 19:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240203124622.40160-1-Brian.Inglis@SystematicSW.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=cygwin-announce@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).