| 2008-03-27 09:06:46 |
James Henstridge |
bug |
|
|
added bug |
| 2008-03-28 05:26:25 |
Stuart Bishop |
pytz: status |
New |
Confirmed |
|
| 2008-03-28 05:26:25 |
Stuart Bishop |
pytz: importance |
Undecided |
Medium |
|
| 2008-06-04 04:23:22 |
Stuart Bishop |
bug |
|
|
assigned to python-tz (Ubuntu) |
| 2009-12-03 15:09:45 |
Petr Machata |
attachment added |
|
pytz_zoneinfo.patch http://launchpadlibrarian.net/36392932/pytz_zoneinfo.patch |
|
| 2009-12-03 17:27:18 |
Petr Machata |
attachment added |
|
pytz-lazier-init.patch http://launchpadlibrarian.net/36397001/pytz-lazier-init.patch |
|
| 2010-08-23 09:49:37 |
Stuart Bishop |
description |
The Debian/Ubuntu packages of pytz include a patch to not install pytz's zoneinfo database and instead load data from the system zoneinfo database. This keeps pytz up to date when system timezone updates are installed which is generally a good idea.
The pytz/__init__.py includes common_timezones and all_timezones lists, which enumerate the time zones in the database pytz was released with. If pytz is instead using the system database, these lists may not be correct (e.g. missing newly added time zones).
It would be nice if pytz could calculate these lists from data found in the zoneinfo directory it is pointed at. If it isn't possible to do this with what tzdata currently installs, this might require it to install an extra index file. |
The Debian/Ubuntu packages of pytz include a patch to not install pytz's zoneinfo database and instead load data from the system zoneinfo database. This keeps pytz up to date when system timezone updates are installed which is generally a good idea.
The pytz/__init__.py includes common_timezones and all_timezones lists, which enumerate the time zones in the database pytz was released with. If pytz is instead using the system database, these lists may not be correct (e.g. missing newly added time zones).
all_timezones and common_timezones should be calculated at run time. all_timezones will need to use os.walk to discover what timezones exist. common_timezones should be loaded from zone.tab, plus a hard coded list of extras such as UTC and US/Eastern.
|
|
| 2011-03-23 11:04:09 |
Bhaskar Kandiyal |
bug |
|
|
added subscriber Bhaskar Kandiyal |
| 2011-08-30 12:49:28 |
Gediminas Paulauskas |
python-tz (Ubuntu): status |
New |
Confirmed |
|
| 2011-08-30 12:49:32 |
Gediminas Paulauskas |
python-tz (Ubuntu): importance |
Undecided |
Medium |
|
| 2011-08-30 12:49:52 |
Gediminas Paulauskas |
bug |
|
|
added subscriber Gediminas Paulauskas |
| 2013-09-06 08:55:26 |
Stuart Bishop |
pytz: status |
Confirmed |
Fix Released |
|
| 2022-11-08 11:51:08 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2022-11-16 14:33:44 |
Benjamin Drung |
bug watch added |
|
https://github.com/stub42/pytz/issues/91 |
|
| 2022-11-16 14:33:44 |
Benjamin Drung |
pytz: importance |
Medium |
Unknown |
|
| 2022-11-16 14:33:44 |
Benjamin Drung |
pytz: status |
Fix Released |
Unknown |
|
| 2022-11-16 14:33:44 |
Benjamin Drung |
pytz: remote watch |
|
github.com/stub42/pytz/issues #91 |
|
| 2022-11-16 16:05:54 |
Bug Watch Updater |
pytz: status |
Unknown |
New |
|
| 2022-11-17 10:12:09 |
Benjamin Drung |
tags |
|
rls-ll-incoming |
|
| 2022-11-18 09:51:28 |
Benjamin Drung |
tags |
rls-ll-incoming |
fr-2987 rls-ll-incoming |
|
| 2022-11-24 16:15:11 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Foundations Bugs |
| 2022-11-24 16:15:16 |
Łukasz Zemczak |
tags |
fr-2987 rls-ll-incoming |
fr-2987 |
|
| 2022-11-24 16:34:01 |
Dirkjan Ochtman |
removed subscriber Dirkjan Ochtman |
|
|
|
| 2023-03-21 10:31:04 |
Benjamin Drung |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-03-21 10:31:04 |
Benjamin Drung |
bug task added |
|
python-tz (Ubuntu Jammy) |
|
| 2023-03-21 10:31:04 |
Benjamin Drung |
nominated for series |
|
Ubuntu Kinetic |
|
| 2023-03-21 10:31:04 |
Benjamin Drung |
bug task added |
|
python-tz (Ubuntu Kinetic) |
|
| 2023-03-21 10:47:01 |
Benjamin Drung |
python-tz (Ubuntu): status |
Confirmed |
Fix Committed |
|
| 2023-03-21 11:33:17 |
Benjamin Drung |
attachment added |
|
python-tz_2022.2.1-1ubuntu0.22.10.0.debdiff https://bugs.launchpad.net/ubuntu/+source/python-tz/+bug/207604/+attachment/5656299/+files/python-tz_2022.2.1-1ubuntu0.22.10.0.debdiff |
|
| 2023-03-21 11:49:41 |
Benjamin Drung |
attachment added |
|
python-tz_2022.1-1ubuntu0.22.04.1.debdiff https://bugs.launchpad.net/ubuntu/+source/python-tz/+bug/207604/+attachment/5656300/+files/python-tz_2022.1-1ubuntu0.22.04.1.debdiff |
|
| 2023-03-21 12:14:29 |
Benjamin Drung |
description |
The Debian/Ubuntu packages of pytz include a patch to not install pytz's zoneinfo database and instead load data from the system zoneinfo database. This keeps pytz up to date when system timezone updates are installed which is generally a good idea.
The pytz/__init__.py includes common_timezones and all_timezones lists, which enumerate the time zones in the database pytz was released with. If pytz is instead using the system database, these lists may not be correct (e.g. missing newly added time zones).
all_timezones and common_timezones should be calculated at run time. all_timezones will need to use os.walk to discover what timezones exist. common_timezones should be loaded from zone.tab, plus a hard coded list of extras such as UTC and US/Eastern.
|
[ Impact ]
The Debian/Ubuntu packages of pytz include a patch to not install pytz's zoneinfo database and instead load data from the system zoneinfo database. This keeps pytz up to date when system timezone updates are installed which is generally a good idea.
The pytz/__init__.py includes common_timezones and all_timezones lists, which enumerate the time zones in the database pytz was released with. If pytz is instead using the system database, these lists may not be correct (e.g. missing newly added time zones).
all_timezones and common_timezones should be calculated at run time. all_timezones will need to use os.walk to discover what timezones exist. common_timezones should be loaded from zone.tab, plus a hard coded list of extras such as UTC and US/Eastern.
[ Test Plan ]
Two autopkgtest test cases were added:
1. Run the upstream unittests
2. Regression tests with all tests that I could come up with.
There are no manual test, because all those test should also be run when there is a tzdata update to prevent regressions.
[ Where problems could occur ]
Dynamically determine the timezones relies on a correct environment and can fail more easily if the environment is broken. python-tz is used in several places (maybe in the installer). The patch might have a performance impact, because the list of timezones is determined completely (but only once) instead of constructing it lazy.
[ Other Info ]
Upstream recommend our approach: https://github.com/stub42/pytz/issues/91#issuecomment-1356628324 |
|
| 2023-03-21 12:25:06 |
Ubuntu Foundations Team Bug Bot |
tags |
fr-2987 |
fr-2987 patch |
|
| 2023-03-26 04:27:47 |
Launchpad Janitor |
python-tz (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2023-03-30 14:13:50 |
Robie Basak |
python-tz (Ubuntu Jammy): status |
New |
Incomplete |
|
| 2023-03-30 14:13:52 |
Robie Basak |
python-tz (Ubuntu Kinetic): status |
New |
Incomplete |
|
| 2023-03-30 22:44:33 |
Benjamin Drung |
description |
[ Impact ]
The Debian/Ubuntu packages of pytz include a patch to not install pytz's zoneinfo database and instead load data from the system zoneinfo database. This keeps pytz up to date when system timezone updates are installed which is generally a good idea.
The pytz/__init__.py includes common_timezones and all_timezones lists, which enumerate the time zones in the database pytz was released with. If pytz is instead using the system database, these lists may not be correct (e.g. missing newly added time zones).
all_timezones and common_timezones should be calculated at run time. all_timezones will need to use os.walk to discover what timezones exist. common_timezones should be loaded from zone.tab, plus a hard coded list of extras such as UTC and US/Eastern.
[ Test Plan ]
Two autopkgtest test cases were added:
1. Run the upstream unittests
2. Regression tests with all tests that I could come up with.
There are no manual test, because all those test should also be run when there is a tzdata update to prevent regressions.
[ Where problems could occur ]
Dynamically determine the timezones relies on a correct environment and can fail more easily if the environment is broken. python-tz is used in several places (maybe in the installer). The patch might have a performance impact, because the list of timezones is determined completely (but only once) instead of constructing it lazy.
[ Other Info ]
Upstream recommend our approach: https://github.com/stub42/pytz/issues/91#issuecomment-1356628324 |
[ Impact ]
The Debian/Ubuntu packages of pytz include a patch to not install pytz's zoneinfo database and instead load data from the system zoneinfo database. This keeps pytz up to date when system timezone updates are installed which is generally a good idea.
The pytz/__init__.py includes common_timezones and all_timezones lists, which enumerate the time zones in the database pytz was released with. If pytz is instead using the system database, these lists may not be correct (e.g. missing newly added time zones).
all_timezones and common_timezones should be calculated at run time. all_timezones will need to use os.walk to discover what timezones exist. common_timezones should be loaded from zone.tab, plus a hard coded list of extras such as UTC and US/Eastern.
Everytime a new timezone is added to tzdata in an update, this timezone cannot be used in pytz with the hardcoded list of timezones. For jammy and kinetic this applies to America/Ciudad_Juarez (when comparing pytz to tzdata 2023c). For bionic the list of missing timezones is even bigger:
* America/Ciudad_Juarez
* America/Nuuk
* Asia/Qostanay
* Europe/Kyiv
* Pacific/Kanton
[ Test Plan ]
Two autopkgtest test cases were added:
1. Run the upstream unittests
2. Regression tests with all tests that I could come up with.
There are no manual test, because all those test should also be run when there is a tzdata update to prevent regressions.
[ Where problems could occur ]
Dynamically determine the timezones relies on a correct environment and can fail more easily if the environment is broken. python-tz is used in several places (maybe in the installer). The patch might have a performance impact, because the list of timezones is determined completely (but only once) instead of constructing it lazy.
[ Other Info ]
Upstream recommend our approach: https://github.com/stub42/pytz/issues/91#issuecomment-1356628324 |
|
| 2023-03-30 22:46:30 |
Benjamin Drung |
description |
[ Impact ]
The Debian/Ubuntu packages of pytz include a patch to not install pytz's zoneinfo database and instead load data from the system zoneinfo database. This keeps pytz up to date when system timezone updates are installed which is generally a good idea.
The pytz/__init__.py includes common_timezones and all_timezones lists, which enumerate the time zones in the database pytz was released with. If pytz is instead using the system database, these lists may not be correct (e.g. missing newly added time zones).
all_timezones and common_timezones should be calculated at run time. all_timezones will need to use os.walk to discover what timezones exist. common_timezones should be loaded from zone.tab, plus a hard coded list of extras such as UTC and US/Eastern.
Everytime a new timezone is added to tzdata in an update, this timezone cannot be used in pytz with the hardcoded list of timezones. For jammy and kinetic this applies to America/Ciudad_Juarez (when comparing pytz to tzdata 2023c). For bionic the list of missing timezones is even bigger:
* America/Ciudad_Juarez
* America/Nuuk
* Asia/Qostanay
* Europe/Kyiv
* Pacific/Kanton
[ Test Plan ]
Two autopkgtest test cases were added:
1. Run the upstream unittests
2. Regression tests with all tests that I could come up with.
There are no manual test, because all those test should also be run when there is a tzdata update to prevent regressions.
[ Where problems could occur ]
Dynamically determine the timezones relies on a correct environment and can fail more easily if the environment is broken. python-tz is used in several places (maybe in the installer). The patch might have a performance impact, because the list of timezones is determined completely (but only once) instead of constructing it lazy.
[ Other Info ]
Upstream recommend our approach: https://github.com/stub42/pytz/issues/91#issuecomment-1356628324 |
[ Impact ]
The Debian/Ubuntu packages of pytz include a patch to not install pytz's zoneinfo database and instead load data from the system zoneinfo database. This keeps pytz up to date when system timezone updates are installed which is generally a good idea.
The pytz/__init__.py includes common_timezones and all_timezones lists, which enumerate the time zones in the database pytz was released with. If pytz is instead using the system database, these lists may not be correct (e.g. missing newly added time zones).
all_timezones and common_timezones should be calculated at run time. all_timezones will need to use os.walk to discover what timezones exist. common_timezones should be loaded from zone.tab, plus a hard coded list of extras such as UTC and US/Eastern.
Everytime a new timezone is added to tzdata in an update, this timezone cannot be used in pytz with the hardcoded list of timezones. For jammy and kinetic this applies to America/Ciudad_Juarez (when comparing pytz to tzdata 2023c). For bionic the list of missing timezones is even bigger:
* America/Ciudad_Juarez
* America/Nuuk
* Asia/Qostanay
* Europe/Kyiv
* Pacific/Kanton
[ Test Plan ]
Two autopkgtest test cases were added:
1. Run the upstream unittests
2. Regression tests with all tests that I could come up with.
There are no manual test, because all those test should also be run when there is a tzdata update to prevent regressions.
To manually test, a newly added timezone to tzdata should be able to be specified:
```
#!/usr/bin/python3
import pytz
pytz.timezone("America/Ciudad_Juarez")
```
This should not raise UnknownTimeZoneError.
[ Where problems could occur ]
Dynamically determine the timezones relies on a correct environment and can fail more easily if the environment is broken. python-tz is used in several places (maybe in the installer). The patch might have a performance impact, because the list of timezones is determined completely (but only once) instead of constructing it lazy.
[ Other Info ]
Upstream recommend our approach: https://github.com/stub42/pytz/issues/91#issuecomment-1356628324 |
|
| 2023-03-31 16:58:16 |
Robie Basak |
python-tz (Ubuntu Kinetic): status |
Incomplete |
Fix Committed |
|
| 2023-03-31 16:58:18 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-03-31 16:58:20 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2023-03-31 16:58:25 |
Robie Basak |
tags |
fr-2987 patch |
fr-2987 patch verification-needed verification-needed-kinetic |
|
| 2023-03-31 16:58:44 |
Robie Basak |
python-tz (Ubuntu Jammy): status |
Incomplete |
Fix Committed |
|
| 2023-03-31 16:58:51 |
Robie Basak |
tags |
fr-2987 patch verification-needed verification-needed-kinetic |
fr-2987 patch verification-needed verification-needed-jammy verification-needed-kinetic |
|
| 2023-04-04 09:33:12 |
Benjamin Drung |
tags |
fr-2987 patch verification-needed verification-needed-jammy verification-needed-kinetic |
fr-2987 patch verification-done verification-done-jammy verification-done-kinetic |
|
| 2023-04-11 17:13:41 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-04-11 17:14:13 |
Launchpad Janitor |
python-tz (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-04-11 17:33:35 |
Launchpad Janitor |
python-tz (Ubuntu Kinetic): status |
Fix Committed |
Fix Released |
|
