[issue7342] str(datetime_obj) doesn't include microseconds if their value is 0

Ezio Melotti added the comment: Done in r76874 (release26-maint), r76875 (py3k), r76876 (release31-maint). -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker

[issue7342] str(datetime_obj) doesn't include microseconds if their value is 0

Ezio Melotti added the comment: Committed in r76804. Leaving it open until I port this to 2.6 and 3.x. -- stage: patch review -> commit review ___ Python tracker ___

[issue7342] str(datetime_obj) doesn't include microseconds if their value is 0

Ezio Melotti added the comment: Simple patch that fixes the test using a datetime object with a specific number of microseconds instead of using datetime.now(). The test only checks that _strptime._strptime returns the correct value for the microseconds, in test_datetime there are already other

[issue7342] str(datetime_obj) doesn't include microseconds if their value is 0

Ezio Melotti added the comment: Yes, I wrote the previous message from a cellphone and I wasn't able to check the doc. It is indeed already documented in datetime.__str__ -- sorry for the noise. I also noticed that the microseconds are not the only thing that can change in datetime.isoformat(),

[issue7342] str(datetime_obj) doesn't include microseconds if their value is 0

Tim Peters added the comment: Ezio, it was Guido's design decision, it was intentional, and it's been documented from the start(*). So you can disagree with it, but you won't get anywhere claiming it's "a bug": intentional, documented behaviors are never "bugs". At best you can make a case fo

[issue7342] str(datetime_obj) doesn't include microseconds if their value is 0

Ezio Melotti added the comment: If __str__ is supposed to produce "nice" output, the microsecond shouldn't be visible at all imho (special cases are not special enough to break the rules). If the date/time object is read by a human he probably doesn't care of the microseconds anyway, if it's

[issue7342] str(datetime_obj) doesn't include microseconds if their value is 0

Tim Peters added the comment: This behavior is intentional and is documented in the datetime.isoformat() docs: """ Return a string representing the date and time in ISO 8601 format, -MM-DDTHH:MM:SS.mm or, if microsecond is 0, -MM-DDTHH:MM:SS ... """ It was Guido's idea ;-) The po

[issue7342] str(datetime_obj) doesn't include microseconds if their value is 0

Antoine Pitrou added the comment: Yes, there is a valid reason. You certainly don't want spurious microseconds to be displayed when a datetime object was constructed from a second-precise source (e.g. parsing e-mail headers). -- nosy: +pitrou ___ Pyt

[issue7342] str(datetime_obj) doesn't include microseconds if their value is 0

New submission from Ezio Melotti : Last night, test_strptime failed on one of the buildbots [1] with the following error: test test_strptime failed -- Traceback (most recent call last): File "C:\buildslave\3.x.moore-windows\build\lib\test\test_strptime.py", line 279, in test_fraction tup, f