Hi.  I found this today and thought I would report.  I could not find anywhere that it was expected behavior.  When using time.ctime() to convert a date which only has 1 digit in the day position it returs a string with 2 spaces after the month vs one.

example
In [2]: import os,time

In [3]: time.ctime(os.path.getmtime('file.cfg'))
Out[3]: 'Tue Dec 13 18:52:58 2011'

In [4]: time.ctime(os.path.getmtime('14d-1.log'))
Out[4]: 'Tue Feb  1 19:53:11 2011'

Is this expected behavior?

That's definitely the expected behavior. It's the same as the C library version of ctime().

But I couldn't find it documented in the Python docs, so I'm changing this to a documentation issue.

Thanks for the report.

asctime() docs say it's a 24 char string.

> asctime() docs say it's a 24 char string.

I'm not sure that all platform conform to this "specification"... which is not future proof!

$ ./python 
Python 3.3.0a0 (default:af1a9508f7fa, Feb 14 2012, 01:18:15) 
[GCC 4.6.2 20111027 (Red Hat 4.6.2-1)] on linux
>>> import time
>>> time.ctime(2**38)
'Wed Jul 14 08:09:04 10680'
>>> len(time.ctime(2**38))
25

I suppose that you can say that the month day is formatted as 2 characters (padded with a space if needed).

Or you could give the strftime specification string that produces the equivalent output.

I was bored, I generated a patch for this.

Hope this helps :)

This should be added to `asctime` too.

The space-padded behaviour complies with the C standard which was the intent - after all, before it was using C `asctime` directly, and says that unlike C asctime, it doesn't have the newline character, meaning that as a rule, it should then behave similar to it, and only exception is marked.

Unfortunately MSVC asctime has been incorrectly using leading zeros (https://stackoverflow.com/q/53894148/918959).

I have created the PR as mentioned, I have added the example for time.ctime() and also added the note to time.asctime.

I have created a PR for the patch that I submitted, as this is my first contribution to the docs, I need to know that how do we decide if a change has to make an entry to `Misc/NEWS.d/next/` or needs `skip news` tag?

I would like to help get this issue merged as it's already been approved by a core developer.

Does anyone object to the change?  Victor made a suggestion on the PR for alternative wording and I wanted to give others a chance to comment on that.

Also, looking at the man page for asctime, they use `Www Mmm dd hh:mm:ss yyyy` as the description of the output.  Maybe it would be helpful to add this since it shows the spacing and explicitly shows the day number taking up 2 characters?

Thanks!

This is not python compatible format, I want something like "%a %b %d %H:%M:%S %Y" to explain it.

I guess what I'm thinking of `Www Mmm dd hh:mm:ss yyyy` as representing isn't so much a format, but rather a literal replacement of where each value has a placeholder in the string (that is, a pattern).  So, even if `Www` doesn't mean anything, to me it means that the first three characters in the string are a Weekday, then there's a space, then Mmm is the month, then a space, then dd is the day number (with zero sometimes suppressed), etc.  

If that is more confusing than not using it, then that's fine.  I just wanted to mention it.

Using %d to me is also confusing since the docs define %d as `Day of the month as a decimal number [01,31]`.  This clearly isn't using 01, but rather suppressing the 0.

I have updated the PR, this time I have kept it really simple, and have added examples showing both the cases.

New changeset 2d32bf1ef23c9e468b2e8afab3c24e7a2047ac36 by Paul Ganssle (Harmandeep Singh) in branch 'master':
bpo-13927: time.ctime and time.asctime return string explantion (GH-11303)
https://github.com/python/cpython/commit/2d32bf1ef23c9e468b2e8afab3c24e7a2047ac36

New changeset 1e17c4d414049ad2b5b6a0a53685efc7a550c5c5 by Miss Islington (bot) in branch '3.8':
bpo-13927: time.ctime and time.asctime return string explantion (GH-11303)
https://github.com/python/cpython/commit/1e17c4d414049ad2b5b6a0a53685efc7a550c5c5

We've merged the PR and I think it resolves this issue, so we can close this issue now. Please let me know if it's not fully resolved and we can re-open.

Thanks Roger for reporting this and Harmandeep for making the PR and requested changes.