Skip to content

test_strftime incorrectly calculates expected week #133940

Closed
@StanFromIreland

Description

@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

Activity

GGyll

GGyll commented on May 19, 2025

@GGyll
Contributor

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

StanFromIreland commented on May 19, 2025

@StanFromIreland
ContributorAuthor

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

GGyll commented on May 19, 2025

@GGyll
Contributor

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

added a commit that references this issue on May 20, 2025

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

e3dda8f
added a commit that references this issue on May 20, 2025

pythongh-133940: test_strftime incorrectly calculates expected week (p…

gpshead

gpshead commented on May 20, 2025

@gpshead
Member

Thanks for the contribution!

4 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    testsTests in the Lib/test dirtype-bugAn unexpected behavior, bug, or error

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      `test_strftime` incorrectly calculates expected week · Issue #133940 · python/cpython

      Follow Lee on X/Twitter - Father, Husband, Serial builder creating AI, crypto, games & web tools. We are friends :) AI Will Come To Life!

      Check out: eBank.nz (Art Generator) | Netwrck.com (AI Tools) | Text-Generator.io (AI API) | BitBank.nz (Crypto AI) | ReadingTime (Kids Reading) | RewordGame | BigMultiplayerChess | WebFiddle | How.nz | Helix AI Assistant