[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

R. David Murray added the comment: I suppose in an ideal world the csv module would have some sort of hookable serialization protocol, like the database modules do :) -- ___ Python tracker

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

Skip Montanaro added the comment: The ultimate culprit here is actually the csv module. :-) It calls str() on every element it's about to write. In my applications which write to CSV files I can special case datetime objects. I will stop swimming upstream. --

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

Guido van Rossum added the comment: Well, I don't know if this sways anything, but I was probably responsible, and I think my argument was something about not all timestamp sources having microseconds, and not wanting to emit the ".00" in that case. If I could go back I'd probably do somet

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

Tim Peters added the comment: I don't know, Skip. Since `.isoformat()` and `str()` have *always* worked this way, and that was intentional, it's probably going to take a strong argument to change either. -- ___ Python tracker

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

Skip Montanaro added the comment: Okay, so no to __str__. What about isoformat? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

Tim Peters added the comment: The decision to omit microseconds when 0 was a Guido pronouncement, back when datetime was first written. The idea is that str() is supposed to be friendly, and for the vast number of applications that don't use microseconds at all, it's unfriendly to shove ".000

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

R. David Murray added the comment: It's not my conclusion. It's Guido's and the other developers who designed datetime. Argue with them. (I'd guess it would be better argued on python-ideas rather than python-dev, but use your own judgement.) -- status: open -> closed _

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

Skip Montanaro added the comment: I don't accept your conclusion. I understand that making %S consume microseconds or ".%f" be "optional" would be a load. What's the problem with forcing __str__ and isoformat to emit microseconds in all cases though? That would allow you to parse what they pro

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

R. David Murray added the comment: It may be simple but as Ezio has pointed out, it has already been rejected :) The problem with being generous in what you accept in this context is that the parsing is using a specific format string, and the semantics of that format string are based on extern

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

Ezio Melotti added the comment: See #7342. -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue19475] Inconsistency between datetime's str()/isoformat() and its strptime() method

New submission from Skip Montanaro: I have a CSV file. Here are a few rows: "2013-10-30 14:26:46.000528","1.36097023829" "2013-10-30 14:26:46.999755","1.36097023829" "2013-10-30 14:26:47.999308","1.36097023829" "2013-10-30 14:26:49.002472","1.36097023829" "2013-10-30 14:26:50","1.36097023829" "2