Skip to content

test_strftime incorrectly calculates expected week #133940

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
StanFromIreland opened this issue May 12, 2025 · 4 comments
Closed

test_strftime incorrectly calculates expected week #133940

StanFromIreland opened this issue May 12, 2025 · 4 comments
Labels
tests Tests in the Lib/test dir type-bug An unexpected behavior, bug, or error

Comments

@StanFromIreland
Copy link
Contributor

StanFromIreland commented May 12, 2025

Bug report

Bug description:

This is not a duplicate of other IST related issues, this is just a bug in the test itself from a quick look. After further investigation it appears this is indeed just a IST bug but the test also calculates it wrong.
From buildbot run (on IST):

======================================================================
FAIL: test_strftime (test.test_strftime.StrftimeTest.test_strftime)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stan/buildarea/3.x.stan-raspbian/build/Lib/test/test_strftime.py", line 65, in test_strftime
    self.strftest1(now)
    ~~~~~~~~~~~~~~^^^^^
  File "/home/stan/buildarea/3.x.stan-raspbian/build/Lib/test/test_strftime.py", line 124, in strftest1
    self.fail("Conflict for %s (%s): expected %s, but got %s"
    ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
              % (e[0], e[2], e[1], result))
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Conflict for %W (week number of the year (Mon 1st)): expected 18, but got 19
Stdout:
strftime test for Mon May 12 18:08:48 2025
----------------------------------------------------------------------
Ran 4 tests in 0.049s

It seems both the expected and returned are wrong, according to this website it should be week 20. Week 0 is days before the first week, so it would exist in our case, if it is counted, then the returned value is correct, but the test is wrong. Test passes in UTC however.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

@StanFromIreland StanFromIreland added the type-bug An unexpected behavior, bug, or error label May 12, 2025
@picnixz picnixz added the tests Tests in the Lib/test dir label May 15, 2025
@GGyll
Copy link
Contributor

GGyll commented May 19, 2025

As per the docs for time:
https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior

Week number of the year (Sunday as the first day of the week) as a zero-padded decimal number.
All days in a new year preceding the first Sunday are considered to be in week 0.

So you can say the week number is 0-indexed since the first week of the year is 0. Although I think the wording makes it confusing, especially since datetime.datetime.now().isocalendar() returns 21

Regarding the test failing on IST, I was not able to reproduce this issue, I tried mocking IST time and got 20 both as expected value and the output (as per today May 19th, 2025). Perhaps this could be an issue regarding ISO 8601 Standard calculating week number by Thursdays, and the US system calculating by number of Sundays?

@StanFromIreland
Copy link
Contributor Author

Just to check, you used Irish Standard Time and not Indian Standard Time?

On my machine:

cpython{main}$ timedatectl
               Local time: Mon 2025-05-19 19:44:06 IST
           Universal time: Mon 2025-05-19 18:44:06 UTC
                 RTC time: Mon 2025-05-19 19:44:05
                Time zone: Europe/Dublin (IST, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: yes
 
Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.
cpython{main}$ ./python -m test test_strftime
Using random seed: 2749947740
0:00:00 load avg: 1.49 Run 1 test sequentially in a single process
0:00:00 load avg: 1.49 [1/1] test_strftime
test test_strftime failed -- Traceback (most recent call last):
  File "cpython/Lib/test/test_strftime.py", line 65, in test_strftime
    self.strftest1(now)
    ~~~~~~~~~~~~~~^^^^^
  File "cpython/Lib/test/test_strftime.py", line 124, in strftest1
    self.fail("Conflict for %s (%s): expected %s, but got %s"
    ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
              % (e[0], e[2], e[1], result))
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Conflict for %W (week number of the year (Mon 1st)): expected 19, but got 20

0:00:00 load avg: 1.49 [1/1/1] test_strftime failed (1 failure)

== Tests result: FAILURE ==

1 test failed:
    test_strftime

Total duration: 51 ms
Total tests: run=4 failures=1
Total test files: run=1/1 failed=1
Result: FAILURE

@GGyll
Copy link
Contributor

GGyll commented May 19, 2025

I tried with Indian, now with Irish and it fails.. looking into this now

gpshead pushed a commit that referenced this issue May 20, 2025
)

Let the system determine the correct tm_wday and tm_isdst.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue May 20, 2025
…ythonGH-134281)

Let the system determine the correct tm_wday and tm_isdst.
(cherry picked from commit e3dda8f)

Co-authored-by: Gustaf <79180496+GGyll@users.noreply.github.com>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue May 20, 2025
…ythonGH-134281)

Let the system determine the correct tm_wday and tm_isdst.
(cherry picked from commit e3dda8f)

Co-authored-by: Gustaf <79180496+GGyll@users.noreply.github.com>
@gpshead
Copy link
Member

gpshead commented May 20, 2025

Thanks for the contribution!

@gpshead gpshead closed this as completed May 20, 2025
gpshead pushed a commit that referenced this issue May 20, 2025
…H-134281) (#134302)

gh-133940: test_strftime incorrectly calculates expected week (GH-134281)

Let the system determine the correct tm_wday and tm_isdst.
(cherry picked from commit e3dda8f)

Co-authored-by: Gustaf <79180496+GGyll@users.noreply.github.com>
gpshead pushed a commit that referenced this issue May 20, 2025
…H-134281) (#134301)

gh-133940: test_strftime incorrectly calculates expected week (GH-134281)

Let the system determine the correct tm_wday and tm_isdst.
(cherry picked from commit e3dda8f)

Co-authored-by: Gustaf <79180496+GGyll@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests Tests in the Lib/test dir type-bug An unexpected behavior, bug, or error
Projects
Archived in project
Development

No branches or pull requests

4 participants