This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author andrei.avk
Recipients andrei.avk, belopolsky, eric.smith, karlcow, p-ganssle, zhanying
Date 2022-01-01.02:38:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1641004699.14.0.329596777554.issue40236@roundup.psfhosted.org>
In-reply-to
Content
> I am open to discussion about trying to rationalize this behavior - it would be a bit tricky but if we moved to our own implementation of the algorithm to calculate %W we could detect this situation and throw an exception.

Paul: 

I'm guessing here but I think the design makes sense from a certain angle: consider that 0-th week is the first partial week of the year. For some date calculations you might want to go forward, and for others you may go back. If you're going back, it's easier to keep the year and the week the same and reference other days within that week, rather than decrementing the year and changing to 12th month.

This leaves the odd case of there being no partial week. Logically 0th week could refer to the last week of previous year, but that feels wrong because you're referring to it as a week of e.g. 2024 when all of its days are in 2023, so it's entirely a 2023 week.

So a precise definition would be to say that 0-th week is always the first week of the year, whether partial or full; while 1-th week is always the first full week. It follows from this definition that sometimes 0-th and 1-th are the same week.

I'll make a test PR to check if that's how time.strptime behaves on all platforms.
History
Date User Action Args
2022-01-01 02:38:19andrei.avksetrecipients: + andrei.avk, belopolsky, eric.smith, karlcow, p-ganssle, zhanying
2022-01-01 02:38:19andrei.avksetmessageid: <1641004699.14.0.329596777554.issue40236@roundup.psfhosted.org>
2022-01-01 02:38:19andrei.avklinkissue40236 messages
2022-01-01 02:38:18andrei.avkcreate