#20855 was meant as a joke, so I'll keep serious responses here.

Nick wrote:

"""
Alexander, my goal is to flip the default assumption in the time discussion. It is clear from the documentation that the current behaviour is intentional, but there is no concrete *use case* given for it. This is in stark contrast to the other types where treating zero or an empty container differently is quite common, and hence generally unsurprising.
"""

I gave a use case on the list:

if dt.time():
   counts[dt.date()] += 1
else:
   counts[dt.date() - timedelta(1)] += 1

I see nothing wrong with this code and I don't think rewriting it as

if dt.time() != datetime.time(0): ..

is an improvement.

"""
This has resulted in a problem, since the default for most types is that all instances are true, and users mistakenly assume that assumption will hold for datetime.time objects. This is particularly likely for newer users that don't have experience with lower level models of time of day as "seconds since midnight" (which is the mental model where the current behaviour makes sense, and the most plausible rationale for its origins).
"""

datetime module types being spelled in lower-case may be enough of a hint to new users that they should expect the instances to behave more like those of builtin types rather than of user-defined classes.