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 for that
they're design errors.

But that won't fly either.  It's no more inconsistent than that, e.g.,
most floating-point numbers in practice aren't usually displayed with an
exponent, but if an exponent is needed, one is added to the output:

>>> .25
0.25
>>> .25 * 10**100
2.5e+99

Overly literal readings don't help your case either.  Yes, __str__ aims
at producing nice output, but it's pedantic to argue as if that is, or
should be, __str__'s /only/ goal.  Python's design just isn't that
simple-minded ;-)  If someone uses non-zero microseconds, presumably
they want to see them.

Utterly trivial mechanical parsing of str() output is a non-goal in Python.

Of course the failing test should be repaired, and that was a good
catch.  But the chance of changing the language to make the test work
as-is is approximately 0%.


(*) The datetime docs already say:

"""
__str__( ) 

For a datetime instance d, str(d) is equivalent to d.isoformat(' '). 
"""