This bug was fixed in the package tzdata - 2023b-1exp1ubuntu1
---------------
tzdata (2023b-1exp1ubuntu1) lunar; urgency=medium
* Merge with Debian experimental (LP: #2012599). Remaining changes:
- Ship ICU 2022g timezone data which are utilized by PHP in tzdata-icu
- Do not rename NEWS into changelog.gz, this fixes a build failure on
moment-timezone.js
- Point Vcs-Browser/Git to Launchpad
* Update the ICU timezone data to 2023a (2023b is not available yet)
* Add autopkgtest test case for ICU timezone data 2023a
* Add autopkgtest test case for pre-1970 timestamps
tzdata (2023b-1exp1) experimental; urgency=medium
* Drop /usr/share/zoneinfo/posix (identical to /usr/share/zoneinfo)
(LP: #2008076)
* Split right/* timezones into separate tzdata-legacy package (LP: #2008076)
* Drop providing tzdata-bookworm from tzdata
tzdata (2023b-1) unstable; urgency=medium
* New upstream version (LP: #2012599):
- Lebanon delays the start of DST this year.
-- Benjamin Drung <bdr...@ubuntu.com> Fri, 24 Mar 2023 14:10:20 +0100
** Changed in: tzdata (Ubuntu Lunar)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/2012599
Title:
tzdata 2023a/2023b/2023c release - Egypt restoring DST
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Bionic:
Triaged
Status in tzdata source package in Focal:
Triaged
Status in tzdata source package in Jammy:
Triaged
Status in tzdata source package in Kinetic:
Triaged
Status in tzdata source package in Lunar:
Fix Released
Bug description:
[ Impact ]
Recently the Egyptian authorities decided to restore DST. The first
switch after the change is expected to take place on last Friday of
April. The upstream tzdata 2023a release already reflects this change.
The 2023a release contains the following changes:
* Egypt now uses DST again, from April through October.
* This year Morocco springs forward April 23, not April 30.
* Palestine delays the start of DST this year.
* Much of Greenland still uses DST from 2024 on.
The 2023c release reverts the changes done in 2023b.
[ Test Plan ]
Test cases were added to the autopkgtest to cover the testing:
* python: test_2023a
* python: test_2023c
* python: test_systemv_timezones (for releases <= 20.04 LTS)
* python-icu: test_2023a (only for kinetic, jammy, focal)
So the test plan is to check that the autopkgtest succeeds.
Alternatively the python test_2023a can be run manually:
* Set system timezone to Egypt (e.g. Africa/Cairo).
* Set system time to 2023-04-27 23:59.
* Wait and observe what happens at 2023-04-28 0:00
[Test Case for releases <= 20.04 LTS]
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. This is done by the test_systemv_timezones test case or can
be checked manually with the following:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
[ Where problems could occur ]
* Systems with incorrect timezone set (e.g. located outside of Egypt
but still using Egyptian time) may observe unexpected time shift.
[ Other Info ]
The autopkgtest for chrony is flaky on jammy and kinetic (see bug
#2002910).
* More information with sources:
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt#:~:text=Daylight%20saving%20time%20(DST)%20has,(DST)%20as%20of%202023.
The SRUs to the stable releases include the recent changes for
generating the debconf template (switching from shell code to Python)
and the timezone mappings in convert_timezone(). This is done to ease
future tzdata updates since those parts of the packaging need to be
updated when timezone are added, renamed, or removed. Having the same
code in that part makes backporting the changes easier. I added a
consistency check to generate_debconf_templates in 2023c-2 which I
want to backport in a future SRU.
Previous SRUs did sometimes forget to update convert_timezone or the
exclusion list for the debconf template for the changes from upstream.
All added tests (for testing the debconf template and
convert_timezone) were also backported to catch missing those changes.
The sorting change of the debconf template was included in the SRU to
allow taking the debconf translations from later releases.
debian/test_timezone_conversions finds following issues in the kinetic
packaging 2022g-0ubuntu0.22.10.1:
```
ERROR: Following 14 timezones can be selected, but will be converted:
Asia/Rangoon
Europe/Uzhgorod
Europe/Zaporozhye
US/Alaska
US/Aleutian
US/Arizona
US/Central
US/Eastern
US/Hawaii
US/Indiana-Starke
US/Michigan
US/Mountain
US/Pacific
US/Samoa
ERROR: Following 5 timezones cannot be selected, but are not converted:
America/Fort_Wayne
America/Indianapolis
America/Knox_IN
America/Louisville
Pacific/Enderbury
ERROR: Following 3 timezones are conversion targets, but are not available:
Asia/Riyadh87
Asia/Riyadh88
Asia/Riyadh89
ERROR: Following 4 timezones are conversion targets, but are not selectable:
America/Indianapolis
Asia/Riyadh87
Asia/Riyadh88
Asia/Riyadh89
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
