Hacker News new | past | comments | ask | show | jobs | submit login

Depends what version python you are on and what work you are doing. Our application deals with user calendars and scheduling across multiple calendar providers (google, microsoft, zoom, you name it), so I deal with the full brunt of timezone complexity all the time.

I use the stdlib datetime.datetime with pytz, with a few in-house helper functions, and it's frankly kinda awful across the board but we deal with it.

Pendulum is really nice, and I want to use it as my daily driver, but I unfortunately found some timezone bugs [1] in v2 that make me hesitant to trust it for what we are doing in production (it screws up DST when doing `.utcoffset()`). If you aren't constantly dealing with data timezones from all over the world, it's probably fine, and it's the only one that the least surprising thing at each step.

Pytz has the whole .localize footgun.

The std datetime lib has horrible ergonomics and can't even cope with IANA timezones until the zoneinfo module was introduced in 3.9. Every single day it bugs me that the classes `datetime` and `time` are lowercase, and there is no consensus on datetime.datetime vs from datetime import datetime.

I tried using arrow and while I applaud them for moving away from the horrible datetime class, that makes it pretty much incompatible with any other time library, including things like pydantic and orjson.

I don't have much experience with dateutil.

1 - https://github.com/sdispater/pendulum/issues/655

Seems to have started in 2.x but is fixed in the 3.0alpha. You have to be specifically using utcoffset, which in general is probably not something you should do and use the timezone types to do conversions, but it was enough to give me pause




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: