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.

classification
Title: Datetime strftime() does not return correct week numbers for 2019
Type: behavior Stage:
Components: Extension Modules, Windows Versions: Python 3.6, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: eamanu, p-ganssle, paul.moore, tim.golden, tr12, zach.ware
Priority: normal Keywords:

Created on 2019-01-28 12:32 by tr12, last changed 2022-04-11 14:59 by admin.

Files
File name Uploaded Description Edit
Python Datetime Issue.JPG tr12, 2019-01-28 12:32 Example of issue
Messages (5)
msg334462 - (view) Author: Tommy Rowland (tr12) Date: 2019-01-28 12:32
This relates to the calculation of the week number from a given datetime, when calling the strftime method. If you call isocalendar() on the datetime.datetime object for the date ‘2018-12-31’, the week number returned is 1, which is correct. This is the same when checking the week attribute for the pandas timestamp equivalent. However, when you call strftime on this object (either datetime or timestamp), passing the ‘%W’ offset string, it returns 53, and then returns 00 for the remainder of the week. It seems that the rest of the weeks in 2019 are out by 1 when returned using this function. This issue seems to be present with the strptime function also.
msg334463 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-01-28 12:56
Possibly related to 35535.
msg334479 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-01-28 16:43
I think this is not a bug. bpo-35535 is probably also intended behavior, but that is less certain.

The misunderstanding here is that %W does not give you the ISO week number, from the documentation:

    %W: Week number of the year (Monday as the first day of the week) as a decimal number.
        All days in a new year preceding the first Monday are considered to be in week 0.


If you want the ISO week number, I think you need %V, which *is* the ISO week:

    >>> datetime(2018, 12, 31).strftime("%V %W")                                                                                            
    '01 53'

I believe this ticket can be closed.
msg334510 - (view) Author: Tommy Rowland (tr12) Date: 2019-01-29 12:04
Hi Paul,

Thank you for the clarification. I can see that %V does indeed return the
correct week number. It seems that when calling strftime, it is possible to
use this in conjunction with %y, but when calling strptime, it is not. Is
this also intended behaviour?

Best regards,

Tommy

On Mon, Jan 28, 2019 at 4:44 PM Paul Ganssle <report@bugs.python.org> wrote:

>
> Paul Ganssle <p.ganssle@gmail.com> added the comment:
>
> I think this is not a bug. bpo-35535 is probably also intended behavior,
> but that is less certain.
>
> The misunderstanding here is that %W does not give you the ISO week
> number, from the documentation:
>
>     %W: Week number of the year (Monday as the first day of the week) as a
> decimal number.
>         All days in a new year preceding the first Monday are considered
> to be in week 0.
>
>
> If you want the ISO week number, I think you need %V, which *is* the ISO
> week:
>
>     >>> datetime(2018, 12, 31).strftime("%V %W")
>
>     '01 53'
>
> I believe this ticket can be closed.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue35841>
> _______________________________________
>
msg334512 - (view) Author: Emmanuel Arias (eamanu) * Date: 2019-01-29 12:24
> I believe this ticket can be closed.

Yes, I think so. How you say, on 35535 there is a detailed explanation about the behavior.
History
Date User Action Args
2022-04-11 14:59:10adminsetgithub: 80022
2019-02-03 00:07:20steve.dowersetnosy: - steve.dower
2019-01-29 12:24:07eamanusetnosy: + eamanu
messages: + msg334512
2019-01-29 12:04:18tr12setmessages: + msg334510
2019-01-28 16:43:55p-gansslesetmessages: + msg334479
2019-01-28 12:56:18p-gansslesetnosy: + p-ganssle
messages: + msg334463
2019-01-28 12:32:09tr12create