This is an overview of the various date/time implementations in Python (that I know of) and why they aren’t good enough. I’m not mentioning why they are good, they may or may not be. The standard library’s datetime module has a lot going for it. This only explains why it’s not good enough. If I’ve missed a library, tell me and I’ll take a look.
The standard library modules
- Too many separate modules, datetime, time, calendaring, etc, with some overlap (and omissions).
- Naive and intentionally crippled timezone implementation.
- Stores datetimes internally as the local time, which makes time zones overly complicated.
- timedelta has a days attribute which is actually not 1 day, but 24 hours.
- Except that the intentionally crippled datetime implementation makes it 23 or 25 hours on DST changes.
Arrow
- Merges dates and datetimes into one class, but dates and datetimes are quite different and probably too different to be the same class. For example, what would the result be of date(2015, 7, 27) + timedelta(11, 23) be? How can you tell the difference between a date and a datetime without asking the object?
Times
- Uses Arrow as it’s implementation, so only included here for completeness.
- Deprecated.
Moment
- Datetimes are mutable, and they shouldn’t be, because then you can’t use them as keys etc. Possibly there could be mutable datetimes as well, but that should not be the default.
- Merges dates and datetimes into one class.
DateTime
- Old, inconsistent and confusing due to being written/extended piecemeal.
- A lot of old cruft like supporting timezones named “EST”.
- Unmaintained.
mxDateTime
- No real time zone support.
dateutil
- Implements a relativedelta class, but uses the stdlib for everything else, so only included for completness.
Delorean
- A wrapper around datetime and pytz, chiefly for a more convenient API (I think).
Filed under: python Tagged: datetime, timezones
