Python date/time libraries
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.
Arrows main criticism towards the standard library is that there is too many classes, like date, time and datetime. However, Arrow does not implement a date() replacement or a time() replacement, an Arrow() object only replaces datetime(). You can’t represent a date or a time with it, Arrow(2014, 5, 6) will return midnight that day. It also will return a timedelta if you subtract two Arrow objects. So it does not improve the situation. Even if you replace all your datetime objects with Arrows, just still need to deal with the exact same number of classes.
And how should time arithmetic work on a date? What is “The 1st of February plus three minutes”? That’s not obvious. A date is the whole day so it actually should be three minutes after midnight on February 2nd”, but if you implement that I think most people would be very surprised. They would get even more surprised that datetime(2014, 11, 2, 5) – datetime(2014, 11, 2) doesn’t return a 5 hour timedelta. (Actual elapsed time between midnight and 5 am that day is six hours). And even if you implement one object that can behave both as a date and a datetime. How can you tell the difference between a date and a datetime without asking the object if they are the same type?
I therefore think there should be separate date and datetime objects.
In addition I’m not happy about how Arrow.replace() works, with Arrow.replace(month=3) sets the month to March, but Arrow.replace(months=3) increases it with three months. The difference is to subtle, and the replace() method should replace, not add. A shift() method would have been better.
All Arrow objects are time zone aware, and default to UTC. But separating time zone aware objects and time zone naive classes are essential, as again, they can’t reliably be compared or subtracted. Just assuming that not specifying a time zone means UTC is not good enough for all cases.
- Uses Arrow as it’s implementation, so only included here for completeness.
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.
- Old, inconsistent and confusing due to being written/extended piecemeal.
- A lot of old cruft like supporting timezones named “EST”.
- No real time zone support.
Implements a relativedelta class, but uses the stdlib for everything else, so only included for completness.
A wrapper around datetime and pytz, chiefly for a more convenient API (I think).