[Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST

Fri Mar 31 15:50:46 UTC 2023

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
Foundations Bugs, 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


