Thanks David Murry for clearing up STINNER Victor comments.  I already feel like I work here;)  So "it's not broke if there exists a workaround".  

In that case it's time to update the documents (which often takes longer than the code to update) to reflect this inconsistency so others won't run into this like I did (it took time to trouble shoot this as it was occurring prior to my logging being set up).  It then took time to trap until I started web browsing:)

State clearly in the API that the output format is either:
"2013-02-05 16:32:24.999000" or      
"2013-02-05 16:32:25"
depending on the time returned.


I would also suggest deprecating the now(), __str__ and any method that exhibits this inconsistent multi-format output behavior since everyone after reading the updated comments will switch to another method immediately for simpler/more robust code. 

David Murry, said "Keep in mind that the str is a *convenience* representation.  As such it is *much* more convenient to not print the zero microseconds in the very common case of constructed datetimes that have zero microseconds."  Interesting since currently datetime does print the zeros microseconds in my example: "2013-02-05 16:32:24.999000" (notice the last 3 zeros are microseconds returned/printed by datetime.now()).  Apparently this is inconvenient by your standards was well.  

I'm moving the status back to open for the documentation update and we'll see how anyone feels about the deprecation.

All these little efforts have added up to something great "Python" and I hope these discussion will help further that cause.  I appreciate everyone who has participated.

Thanks,
Dave