`test_strftime` incorrectly calculates expected week

[StanFromIreland]

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

• gh-133940: test_strftime incorrectly calculates expected week #134281
• [3.14] gh-133940: test_strftime incorrectly calculates expected week (GH-134281) #134301
• [3.13] gh-133940: test_strftime incorrectly calculates expected week (GH-134281) #134302

[GGyll]

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]

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]

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

[gpshead]

Thanks for the contribution!