The current datetime module class hierarchy looks like: object timedelta tzinfo time timetz date datetime datetimetz Several people have noted (on the wiki, and in email), with some bewilderment, that: 1. A timetz object with tzinfo=None acts like a time object. 2. A datetimetz object with tzinfo=None acts like a datetime object. A natural suggestion is to change the hierarchy to: object timedelta tzinfo time date datetime where the current time and datetime classes go away, the current timetz is renamed to time, and the current datetimetz to datetime. I tried that this evening for the Python implementation, and it was easy enough. No subtle problems popped up. The results are checked in to the Python datetime sandbox, as datetime2.py and test_datetime2.py; it appears to be fully functional, and allowed tossing about 10% of the code lines. IIRC, the original motivation for making a finer distinction among objects with and without tzinfo members was to save memory in the objects. Guido thinks that's a red herring, though, and I agree. The C implementation of datetime objects currently has unused "pad bytes" in the structs (due to compiler alignment of struct members), and adding a flag byte to record "does this have a non-None tzinfo member or not?" wouldn't actually consume any more memory. The C implementation would still need to have more than one way to allocate a time/datetime under the covers, in order to avoid allocating an additional pointer field (for the PyObject* tzinfo pointer) when it wasn't needed, so it wouldn't really simplify the C implementation much. It would simplify the user's mental model, and cut out a ton of near-redundant docs (those two are pretty much the same thing <wink>).