[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
This bug was fixed in the package tzdata - 2023c-0ubuntu0.18.04 --- tzdata (2023c-0ubuntu0.18.04) bionic; urgency=medium * New upstream release (LP: #2012599) - 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. * Test timezones using Python pytz module * Add autopkgtest test case for 2023c release * Update debconf template and translations * Check that the old SystemV timezones are still available -- Benjamin Drung Mon, 03 Apr 2023 13:52:56 +0200 -- 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: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Status in tzdata source package in Kinetic: Fix Released 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
This bug was fixed in the package tzdata - 2023c-0ubuntu0.20.04.0 --- tzdata (2023c-0ubuntu0.20.04.0) focal; urgency=medium * New upstream release (LP: #2012599) - 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. * Update the ICU timezone data to 2023c * Test timezones using Python pytz module * Add autopkgtest test case for 2023c release * Add autopkgtest test case for ICU timezone data 2023a/2023c * Update debconf template and translations * Check that the old SystemV timezones are still available -- Benjamin Drung Mon, 03 Apr 2023 13:30:19 +0200 ** Changed in: tzdata (Ubuntu Bionic) 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: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Status in tzdata source package in Kinetic: Fix Released 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
This bug was fixed in the package tzdata - 2023c-0ubuntu0.22.04.0 --- tzdata (2023c-0ubuntu0.22.04.0) jammy; urgency=medium * New upstream release (LP: #2012599) - 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. * Update the ICU timezone data to 2023c * Test timezones using Python's zoneinfo module * Add autopkgtest test case for 2023c release * Add autopkgtest test case for ICU timezone data 2023a/2023c * Update debconf template and translations -- Benjamin Drung Mon, 03 Apr 2023 13:12:42 +0200 ** Changed in: tzdata (Ubuntu Jammy) Status: Fix Committed => Fix Released ** Changed in: tzdata (Ubuntu Focal) 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: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Status in tzdata source package in Kinetic: Fix Released 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
This bug was fixed in the package tzdata - 2023c-0ubuntu0.22.10.0 --- tzdata (2023c-0ubuntu0.22.10.0) kinetic; urgency=medium * New upstream release (LP: #2012599) - 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. * Update the ICU timezone data to 2023c * Test timezones using Python's zoneinfo module * Add autopkgtest test case for 2023c release * Add autopkgtest test case for ICU timezone data 2023a/2023c * Update debconf template and translations -- Benjamin Drung Sun, 02 Apr 2023 15:38:36 +0200 ** Changed in: tzdata (Ubuntu Kinetic) 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: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Status in tzdata source package in Kinetic: Fix Released 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
The successful autopkgtest results can also be seen on https://autopkgtest.ubuntu.com/packages/tzdata (ignore the failing i386; this is due to missing dependencies). ** Tags removed: verification-needed ** Tags added: verification-done -- 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: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Bionic verification. Procedure unchanged. tzdata 2023c-0ubuntu0.18.04 test_2023a (__main__.TestZoneinfo) Test Egypt uses DST again from 2023a release. ... ok test_2023c (__main__.TestZoneinfo) Test Lebanon's reverted DST delay from 2023c release. ... ok (...) test_systemv_timezones (__main__.TestZoneinfo) ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Same procedure again, this time for focal. tzdata 2023c-0ubuntu0.20.04.0 test_2023a (__main__.TestZoneinfo) Test Egypt uses DST again from 2023a release. ... ok test_2023c (__main__.TestZoneinfo) Test Lebanon's reverted DST delay from 2023c release. ... ok (...) test_2023a (__main__.TestICU) Test Egypt uses DST again from 2023a release. ... ok ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Verification for jammy. Same procedure as for kinetic above. tzdata 2023c-0ubuntu0.22.04.0 test_2023a (__main__.TestZoneinfo) Test Egypt uses DST again from 2023a release. ... ok test_2023c (__main__.TestZoneinfo) Test Lebanon's reverted DST delay from 2023c release. ... ok (...) test_2023a (__main__.TestICU) Test Egypt uses DST again from 2023a release. ... ok ** Tags removed: verification-needed-jammy ** Tags added: verification-done-jammy -- 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: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Verification for kinetic. I've run autopkgtests locally on tzdata from the proposed pocket using [1]. All newly added tests were successful. Additionally I've run the Egypt DST test manually, like described for the previously tested version. test_2023a (__main__.TestZoneinfo) Test Egypt uses DST again from 2023a release. ... ok test_2023c (__main__.TestZoneinfo) Test Lebanon's reverted DST delay from 2023c release. ... ok test_2023a (__main__.TestICU) Test Egypt uses DST again from 2023a release. ... ok [1] https://packaging.ubuntu.com/html/auto-pkg-test.html ** Tags removed: verification-needed-kinetic ** Tags added: verification-done-kinetic -- 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: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
13:51 bdrung: tzdata in Bionic has quite a bit of churn in debian/tzdata.templates, including the removal of Pacific-New from tzdata/Zones/US. I didn't see any removals in the later series. Do we have anything that demonstrates that this is safe? Shouldn't the choice be preserved somehow? 14:53 rbasak, previous SRUs forgot to regenerate debian/tzdata.templates. You could use 2022g and regenerate debian/tzdata.templates to see what previous SRUs should have included in their debdiff. 14:54 rbasak, Pacific-New was added but was never used. upstream removed Pacific-New some time ago. 15:13 rbasak, checked that. 2018a removed Pacific-New 15:19 bdrung: yeah but I wouldn't expect removals to be followed in SRUs. If it was user-selectable, then wouldn't dropping it be a regression for users who might have selected it previously? 15:22 rbasak, yes. That regression would have been happened years ago when upstream removed Pacific-New. 15:26 bdrung: OK, so Pacific-New in bionic-updates today is already broken? 15:27 If that's the case then there will be no SRU regression so that's fine, but I'd like to document that somewhere. Can you confirm and I'll just stick this conversation into a bug comment? 15:28 rbasak, I checked the history. Even 2018d-1 did not have Pacific-New as option (the source package has an outdated tzdata.templates). So it was never selectable for bionic users. 15:29 2018d-1 was the version of the bionic release. ** Changed in: tzdata (Ubuntu Bionic) Status: Triaged => Fix Committed ** Tags removed: verification-done-bionic ** Tags added: verification-needed-bionic -- 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: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Hello Dariusz, or anyone else affected, Accepted tzdata into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tzdata/2023c-0ubuntu0.20.04.0 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: tzdata (Ubuntu Focal) Status: Triaged => Fix Committed ** Tags removed: verification-done-focal ** Tags added: verification-needed-focal -- 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: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Hello Dariusz, or anyone else affected, Accepted tzdata into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tzdata/2023c-0ubuntu0.22.04.0 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-jammy. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: tzdata (Ubuntu Jammy) Status: Triaged => Fix Committed ** Tags removed: verification-done-jammy ** Tags added: verification-needed-jammy -- 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: Fix Committed Status in tzdata source package in Kinetic: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Also prepared new ESM updates for trusty and xenial and pushed those to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata -- 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: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached the third iteration of SRU for bionic and force pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/bionic ** Patch added: "tzdata_2023c-0ubuntu0.18.04.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5660392/+files/tzdata_2023c-0ubuntu0.18.04.debdiff -- 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: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached the third iteration of SRU for focal and force pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/focal ** Patch added: "tzdata_2023c-0ubuntu0.20.04.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5660390/+files/tzdata_2023c-0ubuntu0.20.04.0.debdiff -- 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: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached the third iteration of SRU for jammy and force pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/jammy ** Patch added: "tzdata_2023c-0ubuntu0.22.04.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5660370/+files/tzdata_2023c-0ubuntu0.22.04.0.debdiff -- 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: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
** Description changed: [ 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 - ``` -- 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: Fix Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Hello Dariusz, or anyone else affected, Accepted tzdata into kinetic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tzdata/2023c-0ubuntu0.22.10.0 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- kinetic to verification-done-kinetic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-kinetic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: tzdata (Ubuntu Kinetic) Status: Triaged => Fix Committed ** Tags removed: verification-done verification-done-kinetic ** Tags added: verification-needed verification-needed-kinetic -- 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: Fix Committed 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. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Due to our discussion I decided to strip down this upload to update tzdata to 2023c and add the autopkgtests that succeed. All other changes are deferred to follow-up SRUs. Attached the third iteration of SRU for kinetic and force pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/kinetic ** Patch added: "tzdata_2023c-0ubuntu0.22.10.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5660084/+files/tzdata_2023c-0ubuntu0.22.10.0.debdiff -- 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:
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
FTR, we discussed this further in #ubuntu-release earlier. IMHO, while there may be a good reason for the changes, they should be described in SRU bugs so that their impact can be considered by the SRU team, and QA can be tracked if accepted. I asked for either these changes to be removed, or a re-upload with SRU bugs in place. -- 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
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 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Fixing the inconsistencies are also real issues reported by the user. Timezones that can be selected in debconf which will be converted on upgrade were reported in bug #772024. Converting an existing timezone should result in a timezone that can be selected in debconf for a similar reason. Example: Set the timezone to Europe/Kiev (in tzdata < 2022b). Then upgrade to tzdata. The timezone should be updated to Europe/Kyiv and Kyiv should be the selectable entry in debconf. Regarding the translations: Most (or all) of the fuzzy translation are wrong. "Мазатлан" is the Belarus translation of "Mazatlan". Mazatlan is a different city than Metlakatla. In Debian I looked at all fuzzy translations and made them "unfuzzy". Except for city renames (like Kiev to Kyiv) the fuzzy names were wrong. -- 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 Committed 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 Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Also prepared the ESM updates for trusty and xenial and pushed those to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata -- 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 Committed 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 Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Review of Kinetic: This looks much better. Thanks! > * Test convert_timezone for consistency and fix inconsistencies: The fixing of inconsistencies are still potential functional changes in an SRU that need their own justification please. Generally we'll only make changes that affect real users, and avoid making changes that we don't think will cause anyone any problem in practice. That still applies here, and so needs the usual SRU justification that considers "user impact". Normally that would go in a separate SRU bug. But is there really a sufficient user impact to justify making this change in a stable release? Alternatively, could you perhaps use "xfail" type tests, so that they are noted but do not fail the tests in the SRUs? Or, if you really think the risk *to users* is lower with this fixed (eg. better maintainability resulting in lower risk of regression to users in the future), even accounting for the risk of change, then I think it's be reasonable to consider the case on that basis, but the argument should be documented somewhere. > * Update debconf template and translations to 2023c-2 The translations changes don't look right to me. For example, in be.po: @@ -1278,10 +1278,8 @@ msgstr "Мэрыда" #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates:3001 -#, fuzzy -#| msgid "Mazatlan" msgid "Metlakatla" -msgstr "Мазатлан" +msgstr "" #. Type: select #. Choices Why is this translation being dropped? I dropped your translation updates, reran debconf-updatepo myself, and got far fewer changes. Is this because previous changes since dropped have been carried forward in lost translations? Please could you check? -- 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 Committed 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 Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
** Patch added: "tzdata_2023c-0ubuntu0.18.04.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5659480/+files/tzdata_2023c-0ubuntu0.18.04.debdiff -- 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 Committed 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 Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached SRU debdiff for bionic and force pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/bionic -- 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 Committed 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 Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached SRU debdiff for focal and force pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/focal ** Patch added: "tzdata_2023c-0ubuntu0.20.04.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5659472/+files/tzdata_2023c-0ubuntu0.20.04.0.debdiff -- 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 Committed 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 Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached SRU debdiff for jammy and force pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/jammy ** Patch added: "tzdata_2023c-0ubuntu0.22.04.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5659432/+files/tzdata_2023c-0ubuntu0.22.04.0.debdiff -- 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 Committed 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 Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Thanks for the detailed response. I stripped down the SRU to the absolute minimum (backport all test cases and fix the issues found by the test cases). Building timezones that differ pre-1970 (LP: #2003797) will be deferred to a subsequent separate SRU. Generating debconf templates with Python instead of bash has some consistency checks included. I will probably have to write test cases to have those consistency checks in the stable releases. Attached SRU debdiff for kinetic and force pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/kinetic ** Patch added: "tzdata_2023c-0ubuntu0.22.10.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5659119/+files/tzdata_2023c-0ubuntu0.22.10.0.debdiff -- 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 Committed 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 Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Summary: there are too many apparently SRU-inappropriate changes bundled into this upload; please remove them and supply the minimal necessary changes only. Full review: This bug has had some unavoidable churn in -proposed due to external factors resulting in multiple releases of tzdata upstream in quick succession. This type of thing usually increases the risk of error in my experience, so I gave this a more thorough SRU review than usual from the perspective of the changes that would be experienced by users. Specifically this is the diff to this upload all the way from what is currently in the -updates pockets. The pulling in of the actual upstreams (tzdata and icu-data) look fine, assuming that it's OK for the icu-data version to mismatch tzdata as the newest icu-data wasn't available at the time of upload. I haven't checked the updates to *.pot and *.po but I assume that they are also fine. The addition and improvement of automated tests are always OK and very welcome. However, some remaining changes I'm not sure about. These weren't documented in the SRU paperwork, though we (bdrung and I) did discuss them extensively in #ubuntu-release - thank you for explaining them. However I'm still not sure if these changes are appropriate for an SRU. Generating debconf templates with Python instead of bash seems like a reasonable improvement, but I'd expect this to be done in the development release only. SRU policy says: > ...the requirements for stable updates are not necessarily the same as those in the development release. When preparing future releases, one of our goals is to construct the most elegant and maintainable system possible, and this often involves fundamental improvements to the system's architecture, rearranging packages to avoid bundled copies of other software so that we only have to maintain it in one place, and so on. However, once we have completed a release, the priority is normally to minimise risk caused by changes not explicitly required to fix qualifying bugs, and this tends to be well-correlated with minimising the size of those changes. As such, the same bug may need to be fixed in different ways in stable and development releases. I'd therefore not expect this change to be present in the SRU, but instead for the existing mechanism to be used. If the existing mechanism is broken or not practical in some way, then I think this needs a separate SRU bug with a full justification of the reasons so that regression risk can be considered, and a QA plan can be agreed. I appreciate that you added a dep8 test, but it isn't clear to me that the dep8 test covers *all* the previous behaviour. That discussion should happen in that bug. There are also multiple and extensive changes and refactorings to debian/tzdata.config. Some of these are unnecessary (reordering and normalising of shell syntax) and these mask the remaining changes, making the rest harder to review. Looking past those, there are some additional indirections, but also the removal of at least one indirection (upstream source at [1]) that we discussed. There's also the new use of convert_timezone. If these changes are necessary then they should be covered by separate bugs with their own individual SRU justifications. I've tried to cover what would be needed if you feel you *must* push these additional changes in an SRU. But please also consider that this consumes a great deal of SRU reviewers' time (which is currently in short supply), and the answer may still be no. I strongly suggest that you simply stop trying to push extensive changes in SRUs except where there's actually a significant and direct benefit to users to do so. I think it'll probably be fine to just update upstream, icu-data and update the templates with the existing bash generator only? This would then be much easier to review and land safely. Note that I've not actually found anything wrong with your changes here. But it's not enough for the upload to merely be correct. It's also necessary to demonstrate to others why and how it is correct, as well as why and how choices have been made such that the risk of an inadvertent oversight has been minimised. This aspect is currently mostly missing, resulting in a significant review burden on others. This apsect should be taken into consideration when deciding whether to seek an SRU backport of something or not. [1] https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/commit/?id=4c2b898ef99c134a9d202405643136d4b0d38048 ** Changed in: tzdata (Ubuntu Bionic) Status: Fix Committed => Triaged ** Changed in: tzdata (Ubuntu Focal) Status: Fix Committed => Triaged ** Changed in: tzdata (Ubuntu Jammy) Status: Fix Committed => Triaged ** Changed in: tzdata (Ubuntu Kinetic) Status: Fix Committed => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu.
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
** Description changed: [ 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 + ``` -- 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 Committed Status in tzdata source package in Bionic: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed Status in tzdata source package in Lunar: Fix Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
** Description changed: [ 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. + 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. -- 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 Committed Status in tzdata source package in Bionic: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed Status in tzdata source package in Lunar: Fix Committed 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
** Description changed: [ 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 include the recent changes for generating the - debconf template (switching from shell code to Python) and the timezone - mappings in convert_timezone(). Previous SRUs did forget to update them - for the changes from upstream. All added tests (for testing the debconf - template and convert_timezone) were also backported. + 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. + + 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. ** Description changed: [ 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:
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
** Description changed: [ 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 include the recent changes for generating the - debconf template and the timezone mappings in convert_timezone(). - Previous SRUs did forget to update them for the changes from upstream. - All added tests were also backported. + debconf template (switching from shell code to Python) and the timezone + mappings in convert_timezone(). Previous SRUs did forget to update them + for the changes from upstream. All added tests (for testing the debconf + template and convert_timezone) were also backported. -- 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 Committed Status in tzdata source package in Bionic: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed Status in tzdata source package in Lunar: Fix Committed 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:
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached 2022c SRU for bionic and pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/bionic ** Description changed: [ 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. Subsequently, these should be checked for using the following: + 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 include the recent changes for generating the debconf template and the timezone mappings in convert_timezone(). Previous SRUs did forget to update them for the changes from upstream. All added tests were also backported. ** Patch added: "tzdata_2023c-0ubuntu0.18.04.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5658652/+files/tzdata_2023c-0ubuntu0.18.04.0.debdiff -- 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 Committed Status in tzdata source package in Bionic: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed Status in tzdata source package in Lunar: Fix Committed 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.
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached 2023c SRU for focal and pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/focal ** Patch added: "tzdata_2023c-0ubuntu0.20.04.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5658647/+files/tzdata_2023c-0ubuntu0.20.04.0.debdiff -- 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 Committed Status in tzdata source package in Bionic: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed Status in tzdata source package in Lunar: Fix Committed 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-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. Subsequently, these should be checked for using 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 include the recent changes for generating the debconf template and the timezone mappings in convert_timezone(). Previous SRUs did forget to update them for the changes from upstream. All added tests were also backported. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached 2023c SRU for jammy and pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/jammy ** Patch added: "tzdata_2023c-0ubuntu0.22.04.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5658646/+files/tzdata_2023c-0ubuntu0.22.04.0.debdiff -- 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 Committed Status in tzdata source package in Bionic: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed Status in tzdata source package in Lunar: Fix Committed 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-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. Subsequently, these should be checked for using 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 include the recent changes for generating the debconf template and the timezone mappings in convert_timezone(). Previous SRUs did forget to update them for the changes from upstream. All added tests were also backported. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
Attached 2022c SRU for kinetic and pushed the changes to https://code.launchpad.net/~ubuntu-core- dev/ubuntu/+source/tzdata/+git/tzdata/+ref/ubuntu/kinetic ** Patch added: "tzdata_2023c-0ubuntu0.22.10.0.debdiff" https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+attachment/5658645/+files/tzdata_2023c-0ubuntu0.22.10.0.debdiff -- 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 Committed Status in tzdata source package in Bionic: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed Status in tzdata source package in Lunar: Fix Committed 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-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. Subsequently, these should be checked for using 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 include the recent changes for generating the debconf template and the timezone mappings in convert_timezone(). Previous SRUs did forget to update them for the changes from upstream. All added tests were also backported. 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
[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST
** Summary changed: - tzdata 2023a/2023b release - Egypt restoring DST + tzdata 2023a/2023b/2023c release - Egypt restoring DST ** Description changed: [ 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_2023b + * python: test_2023c * 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. Subsequently, these should be checked for using 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 ] * 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 include the recent changes for generating the debconf template and the timezone mappings in convert_timezone(). Previous SRUs did forget to update them for the changes from upstream. All added tests were also backported. ** Description changed: [ 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-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. Subsequently, these should be checked for using 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 include the recent changes for generating the debconf template and the timezone mappings in convert_timezone(). Previous SRUs did forget to update them for the changes from upstream. All added tests were also backported. -- 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 Committed Status in tzdata source package in Bionic: Fix Committed Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Kinetic: Fix Committed Status in tzdata source package in Lunar: Fix Committed Bug description: [ Impact ] Recently
