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

2009-12-18 Thread Ezio Melotti
Ezio Melotti ezio.melo...@gmail.com 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

2009-12-13 Thread Ezio Melotti
Ezio Melotti ezio.melo...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue7342

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

2009-12-07 Thread Ezio Melotti
Ezio Melotti ezio.melo...@gmail.com 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

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

2009-11-20 Thread Tim Peters
Tim Peters tim.pet...@gmail.com 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

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

2009-11-20 Thread Ezio Melotti
Ezio Melotti ezio.melo...@gmail.com 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

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

2009-11-19 Thread Ezio Melotti
Ezio Melotti ezio.melo...@gmail.com 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

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

2009-11-17 Thread Ezio Melotti
New submission from Ezio Melotti ezio.melo...@gmail.com: 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

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

2009-11-17 Thread Antoine Pitrou
Antoine Pitrou pit...@free.fr 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

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

2009-11-17 Thread Tim Peters
Tim Peters tim.pet...@gmail.com 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