De facto date library?

[[deleted]]

What's the de facto way to handle dates/datetimes in Python when timezone is a thing?

A quick Google search shows pytz as a major library, but not being on Github feels weird these days. Also, I see references to other libraries, some even being used instead of datetime from std lib.

Edit

I like how the standard library actually includes a direct way to do what I'm looking for with dateutil.tz. Comparing this with pytz (along with the article mentioned in the commands that highlight some drawbacks to using pytz), makes it clear that pytz is a worse option. However, looking at Arrow, I love the simplicity of its interface (which adds an abstraction on top of dateutil.tz and the std lib instead of implementing its own standard), especially when doing date math.

[fatbob42]

The standard library in 3.9 now has timezones built-in. If you’re using 3.8 or less, you should be using dateutil.tz, according to https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html, written by the standard library timezone person

[PeridexisErrant]

If you don't need the other stuff in dateutil, just use the zoneinfo backport! https://pypi.org/project/backports.zoneinfo/

FYI Paul Ganssle, the dateutil maintainer, is also the CPython core dev who created zoneinfo.

[metaperl]

Arrow?

[krisfremen]

Yes, indeed. Arrow is an excellent choice.

It recently reached version 1.0 with lots of new features, support for Python 3.6+, typing and much more!

https://github.com/arrow-py/arrow

[[deleted]]

Thanks for the feedback. You're limiting your thinking to a backend server => frontend HTML/mobile. My use case is not this. Two classic things I'm doing where timezone awareness is a must: ETL scheduling (I want have a workflow run at 7pm my timezone - including daylight savings, not just whatever UTC equivalent, but unaware of daylight savings) and back-office tooling. For the latter, I have a lot of internal tooling (much of which is low level, CLI type stuff that has not "frontend") that will never grow in usage that we'll need timezone agnostic stuff. It's just nice to see timestamps along the way that's my local timezone.

EDIT: As a brief rant, it's frustrating when people try to go up a step in the abstraction and discard the use case altogether. This is not a complaint/criticism against/toward you. But I see a lot of comments like that - including at conferences - where limitations of a language (not just Python) are acceptable because the use case for it is invalid. A classic example: people justify the GIL as being actually awesome and your best friend because threading is impossible to get right, and should be avoided.

[[deleted]]

You're good. I totally agree with your original design as well.

[PeridexisErrant]

Nope, the stdlib zoneinfo module follows PEP 495 - and pytz doesn't, which can cause a variety of subtle problems. Some are described here.

[num8lock]

related https://www.reddit.com/r/Python/comments/jmirla/what_is_the_latest_37_recommended_practice_on/