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.

Title: Default values for zero in time.strftime()
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.7, Python 3.6
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: belopolsky, brett.cannon, denis-osipov, r.david.murray
Priority: normal Keywords:

Created on 2017-09-17 17:06 by denis-osipov, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (9)
msg302374 - (view) Author: Denis Osipov (denis-osipov) * Date: 2017-09-17 17:06
Now default values for zero in time.strftime returns string with day of week value 1:

>>> time.strftime("%Y %m %d %H %M %S %w %j", (2000,)+(0,)*8)
'2000 01 01 00 00 00 1 001'

while 2000-01-01 is Saturday (=6th day of week).

Now each illegal value (day of month < 1 etc.) are forced to a correct one (by the way why now day of week isn't 0=Sunday and forced to 1). Maybe strftime also should force day of week to according to the date (%Y %m %d) if it's given.

>>> time.strftime("%Y %m %d %H %M %S %w %j", (2000,)+(0,)*8)
'2000 01 01 00 00 00 6 001'
msg302452 - (view) Author: Denis Osipov (denis-osipov) * Date: 2017-09-18 13:38
If it's really a bug I could make PR with changes in timemodule.c (in gettmarg() and checktm() functions). But I'm not sure that it's not intended behavior.
msg302472 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-09-18 16:25
Generally we're just reporting whatever the platform strftime does.  Is that what happens in this case?
msg302500 - (view) Author: Denis Osipov (denis-osipov) * Date: 2017-09-19 03:34
It seems strange to me that time.strftime() returns formatted date with wrong day of week and day of year values. So, I think it's probably a bug.
But I'm just learning Python and programming and I think that it can be intentional behavior.
If it's a bug I'd like to try to fix it. Otherwise could someone tell me why this behavior is OK?
msg302525 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-09-19 13:35
Well, the first question that needs to be answered is: if you call the C strftime with the same arguments, what result do you get?  Because if it is the C strftime doing this, then it is not a bug in Python, whether it is correct behavior or not.
msg302548 - (view) Author: Denis Osipov (denis-osipov) * Date: 2017-09-19 17:16
Yes, C strftime returns the same. Inside of Python time.strftime() in Windows we give struct tm with inconsistent attributes (year, mon, mday and wday,yday) as argument for C strftime().

Before it timemodule does a lot of work to parse arguments of time.strftime() and check if all values in obtained struct tm are correct. Also it force values of some attributes to correct ones. Why don't make one more step (e.g. call C mktime before C strftime) to give C function a struct time argument with all consistent attributes?

Or Python time.strftime() should return exactly the same as C strftime?
msg302551 - (view) Author: Denis Osipov (denis-osipov) * Date: 2017-09-19 17:52
Actually now Python time.strftime not always returns the same value as C strftime with the same arguments, because timemodule make some refining of raw argument values to avoid errors.
msg302554 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-09-19 18:22
Yes, I think we can "fix" some things.  I don't know if this falls into the class of things we should fix.  I'll leave that decision to people with more experience with time stuff.
msg302584 - (view) Author: Denis Osipov (denis-osipov) * Date: 2017-09-20 03:31
Thank you for your answers. It's what I want to know. It looks like I shouldn't try to fix (to break) something that works well enough.

If nobody minds I'll close the issue with not a bug resolution.
Date User Action Args
2022-04-11 14:58:52adminsetgithub: 75679
2017-09-20 08:58:29denis-osipovsetstatus: open -> closed
resolution: not a bug
stage: resolved
2017-09-20 03:31:16denis-osipovsetmessages: + msg302584
2017-09-19 18:22:31r.david.murraysetmessages: + msg302554
2017-09-19 17:52:43denis-osipovsetmessages: + msg302551
2017-09-19 17:16:34denis-osipovsetmessages: + msg302548
2017-09-19 13:35:29r.david.murraysetmessages: + msg302525
2017-09-19 03:34:04denis-osipovsetmessages: + msg302500
2017-09-18 16:25:45r.david.murraysetnosy: + r.david.murray, belopolsky
messages: + msg302472
2017-09-18 13:38:29denis-osipovsetmessages: + msg302452
2017-09-17 22:05:04rhettingersetassignee: brett.cannon

nosy: + brett.cannon
2017-09-17 17:06:56denis-osipovcreate