fixes #619 wrong weeknumber for 31.12.2018 #621

BT-sschmid · 2019-01-07T19:55:16Z

The weeknumber was calculated to 53, but by definition the value
must compute to 1.

the fix will compute the weeknumber by using date.isocalendar if
locale.first_week_day == 0.

Also the computation of the year format 'YYYY' is replaced by isocalendar.

Tests added.

Fixes #619

codecov-io · 2019-01-07T20:00:00Z

Codecov Report

Merging #621 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #621   +/-   ##
=======================================
  Coverage   90.31%   90.31%           
=======================================
  Files          24       24           
  Lines        4129     4129           
=======================================
  Hits         3729     3729           
  Misses        400      400

Impacted Files	Coverage Δ
babel/dates.py	`91.55% <100%> (+0.02%)`	⬆️
babel/_compat.py	`98.03% <0%> (-0.08%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b7dda2a...085a397. Read the comment docs.

The weeknumber was calculated to 53, but by definition the value must compute to 1. the fix will compute the weeknumber by using date.isocalendar if locale.first_week_day == 0. Also the computation of the year format 'YYYY' is replaced by isocalendar. Tests added.

babel/dates.py

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib. So, this commit mitigate the issue by guessing the expected value even if the result is wrong. [0]: python-babel/babel#621 [1]: python-babel/babel#887 [2]: https://sources.debian.org/patches/python-babel/2.10.3-1/

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib. So, this commit mitigate the issue by guessing the expected value even if the result is wrong. [0]: python-babel/babel#621 [1]: python-babel/babel#887 [2]: https://sources.debian.org/patches/python-babel/2.10.3-1/ closes #168132 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib. So, this commit mitigate the issue by guessing the expected value even if the result is wrong. [0]: python-babel/babel#621 [1]: python-babel/babel#887 [2]: https://sources.debian.org/patches/python-babel/2.10.3-1/ X-original-commit: 426fc56

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib. So, this commit mitigate the issue by guessing the expected value even if the result is wrong. [0]: python-babel/babel#621 [1]: python-babel/babel#887 [2]: https://sources.debian.org/patches/python-babel/2.10.3-1/ closes #168786 X-original-commit: 426fc56 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com> Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib. So, this commit mitigate the issue by guessing the expected value even if the result is wrong. [0]: python-babel/babel#621 [1]: python-babel/babel#887 [2]: https://sources.debian.org/patches/python-babel/2.10.3-1/ closes #168777 X-original-commit: 426fc56 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com> Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib. So, this commit mitigate the issue by guessing the expected value even if the result is wrong. [0]: python-babel/babel#621 [1]: python-babel/babel#887 [2]: https://sources.debian.org/patches/python-babel/2.10.3-1/ closes #168765 X-original-commit: 426fc56 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com> Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib. So, this commit mitigate the issue by guessing the expected value even if the result is wrong. [0]: python-babel/babel#621 [1]: python-babel/babel#887 [2]: https://sources.debian.org/patches/python-babel/2.10.3-1/ closes #168747 X-original-commit: 426fc56 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com> Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib. So, this commit mitigate the issue by guessing the expected value even if the result is wrong. [0]: python-babel/babel#621 [1]: python-babel/babel#887 [2]: https://sources.debian.org/patches/python-babel/2.10.3-1/ closes odoo#168132 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Babel has a very long standing bug on computing ISO weeks / year-week. python-babel/babel#621 fixed some cases but broke others. Debian decided to revert it[^1] rather than actually fix things up and Ubuntu shipped that patch in Noble, which is awesome (not): test cases embedding either behavior flip around depending whether they run or noble or not. python-babel/babel#887 was opened to fix the issue but left to rot then closed when I mistakenly-ish deleted my personal fork of babel. While technically we could monkeypatch babel and replace functions wholesale (both versions so it works everywhere), just give up and instead compute the weeknumber ourselves in the context of `read_group([X:week])`: - For ISO locales, delegate to the stdlib which does that fine. - For non-ISO locales, assume that the week containing the first day of the year is the first week, and make the executive decision that all days in that calendar week are part of W01. The alternative would be to implement a split / overlapping week system where the same week is both W53 $YEAR and W01 $YEAR+1, and I really have no desire to deal with that from a UI/UX perspective. Fix tests embedding incorrect week assignments: - For `test_group_by_week`, redo the entire set (somewhat more declaratively / data driven, though not quite table-driven) to ensure the assignments are correct, and assert that the locales have the properties we assume with respect to 1dow. - For `test_read_progress_bar`, the entire thing was a fever dream of wonky pseudo-split week where 2019 had no week 1. [^1]: https://sources.debian.org/patches/python-babel/2.10.3-1/

Babel has a very long standing bug on computing ISO weeks / year-week. python-babel/babel#621 fixed some cases but broke others. Debian decided to revert it[^1] rather than actually fix things up and Ubuntu shipped that patch in Noble, which is awesome (not): test cases embedding either behavior flip around depending whether they run or noble or not. python-babel/babel#887 was opened to fix the issue but left to rot then closed when I mistakenly-ish deleted my personal fork of babel. While technically we could monkeypatch babel and replace functions wholesale (both versions so it works everywhere), just give up and instead compute the weeknumber ourselves in the context of `read_group([X:week])`: - For ISO locales, delegate to the stdlib which does that fine. - For non-ISO locales, assume that the week containing the first day of the year is the first week, and make the executive decision that all days in that calendar week are part of W01. The alternative would be to implement a split / overlapping week system where the same week is both W53 $YEAR and W01 $YEAR+1, and I really have no desire to deal with that from a UI/UX perspective. Fix tests embedding incorrect week assignments: - For `test_group_by_week`, redo the entire set (somewhat more declaratively / data driven, though not quite table-driven) to ensure the assignments are correct, and assert that the locales have the properties we assume with respect to 1dow. - For `test_read_progress_bar`, the entire thing was a fever dream of wonky pseudo-split week where 2019 had no week 1. [^1]: https://sources.debian.org/patches/python-babel/2.10.3-1/ closes #170995 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Babel has a very long standing bug on computing ISO weeks / year-week. python-babel/babel#621 fixed some cases but broke others. Debian decided to revert it[^1] rather than actually fix things up and Ubuntu shipped that patch in Noble, which is awesome (not): test cases embedding either behavior flip around depending whether they run or noble or not. python-babel/babel#887 was opened to fix the issue but left to rot then closed when I mistakenly-ish deleted my personal fork of babel. While technically we could monkeypatch babel and replace functions wholesale (both versions so it works everywhere), just give up and instead compute the weeknumber ourselves in the context of `read_group([X:week])`: - For ISO locales, delegate to the stdlib which does that fine. - For non-ISO locales, assume that the week containing the first day of the year is the first week, and make the executive decision that all days in that calendar week are part of W01. The alternative would be to implement a split / overlapping week system where the same week is both W53 $YEAR and W01 $YEAR+1, and I really have no desire to deal with that from a UI/UX perspective. Fix tests embedding incorrect week assignments: - For `test_group_by_week`, redo the entire set (somewhat more declaratively / data driven, though not quite table-driven) to ensure the assignments are correct, and assert that the locales have the properties we assume with respect to 1dow. - For `test_read_progress_bar`, the entire thing was a fever dream of wonky pseudo-split week where 2019 had no week 1. [^1]: https://sources.debian.org/patches/python-babel/2.10.3-1/ X-original-commit: 75c6331

Babel has a very long standing bug on computing ISO weeks / year-week. python-babel/babel#621 fixed some cases but broke others. Debian decided to revert it[^1] rather than actually fix things up and Ubuntu shipped that patch in Noble, which is awesome (not): test cases embedding either behavior flip around depending whether they run or noble or not. python-babel/babel#887 was opened to fix the issue but left to rot then closed when I mistakenly-ish deleted my personal fork of babel. While technically we could monkeypatch babel and replace functions wholesale (both versions so it works everywhere), just give up and instead compute the weeknumber ourselves in the context of `read_group([X:week])`: - For ISO locales, delegate to the stdlib which does that fine. - For non-ISO locales, assume that the week containing the first day of the year is the first week, and make the executive decision that all days in that calendar week are part of W01. The alternative would be to implement a split / overlapping week system where the same week is both W53 $YEAR and W01 $YEAR+1, and I really have no desire to deal with that from a UI/UX perspective. Fix tests embedding incorrect week assignments: - For `test_group_by_week`, redo the entire set (somewhat more declaratively / data driven, though not quite table-driven) to ensure the assignments are correct, and assert that the locales have the properties we assume with respect to 1dow. - For `test_read_progress_bar`, the entire thing was a fever dream of wonky pseudo-split week where 2019 had no week 1. [^1]: https://sources.debian.org/patches/python-babel/2.10.3-1/ closes #171135 X-original-commit: 75c6331 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

BT-sschmid force-pushed the master branch from 5db1e15 to bb7e8c7 Compare January 7, 2019 20:17

akx reviewed Jan 24, 2019

View reviewed changes

babel/dates.py Show resolved Hide resolved

added comment

085a397

akx merged commit ea5bc49 into python-babel:master Mar 1, 2019

xmo-odoo mentioned this pull request Jun 15, 2022

Fix incorrect iso week-years (w) #887

Closed

d-fence mentioned this pull request Jun 5, 2024

[FIX] test_new_api: mitigate babel issue odoo/odoo#168132

Closed

fw-bot mentioned this pull request Jun 10, 2024

[FW][FIX] test_new_api: mitigate babel issue odoo/odoo#168747

Closed

fw-bot mentioned this pull request Jun 10, 2024

[FW][FIX] test_new_api: mitigate babel issue odoo/odoo#168765

Closed

fw-bot mentioned this pull request Jun 10, 2024

[FW][FIX] test_new_api: mitigate babel issue odoo/odoo#168777

Closed

fw-bot mentioned this pull request Jun 10, 2024

[FW][FIX] test_new_api: mitigate babel issue odoo/odoo#168786

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fixes #619 wrong weeknumber for 31.12.2018 #621

fixes #619 wrong weeknumber for 31.12.2018 #621

BT-sschmid commented Jan 7, 2019

codecov-io commented Jan 7, 2019 •

edited

Loading

fixes #619 wrong weeknumber for 31.12.2018 #621

fixes #619 wrong weeknumber for 31.12.2018 #621

Conversation

BT-sschmid commented Jan 7, 2019

codecov-io commented Jan 7, 2019 • edited Loading

Codecov Report

codecov-io commented Jan 7, 2019 •

edited

Loading