Ok, I don't understand though why the bug hasn't been fixed and is there any other widely used time localization library that makes the same mistake - not just in python but other languages?
Why hasn't the bug been fixed? I'm not sure! But looking at the code it seems like this problem has existed for the past 9 years. My guess is that the developers and maintainers never saw it as an actual problem, despite its ubiquity.
It would be less of a problem if pytz defaulted to the last offset in the database rather than the first.
pytz defaulting to the last offset instead of the first would cause a lot more silent breakages, because it would probably be right about half the time, and wrong about half the time, and even when it's wrong it won't be obvious. Defaulting to the first value in the list is as close as pytz can come to failing loudly without actually raising an exception, because it's obviously wrong nearly 100% of the time.
There seem to be two commonly understood meanings of timezone which are confused in UIs and APIs: a geographical area which follows a particular winter and summertime regime over the year; and a particular offset from UTC like GMT or BST. I've seen a lot of bad design rooted in this confusion.
Nowadays people use higher level libs such as pendulum:
>>> print(pendulum.datetime(2019, 5, 21, 12, 30, tz='America/New_York'))
2019-05-21T12:30:00-04:00
Like skilpat said, dateutil is a better fit that pytz, and hence pendulum uses it, as well as pytzdata, to stay up to date.
Your assertion reminded me of this funny dialog about JS: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
Using pendulum is not complicated.
You can skim the doc in 5 minutes, your intern can do it too.
This is one of those tools that removes complexity when you use them.
Also, pendulum and the stdlib datetime module are compatible, making migration painless:
>>> pendulum.now() - datetime.now(pendulum.now().tz)
<Period [2019-05-26T16:57:35.872732+02:00 -> 2019-05-26T16:57:35.872141+02:00]>
I see only wins.
Discoverability is a very big issue in general, and with these libraries in particular. I for example have been working with Python for almost a decade and follow the community quite closely, but can't recall hearing of pendulum before. Last time I investigated this, the cool libraries to use were arrow and delorean. How are people expected to keep up to date with every cool new thing?
For much of the work I do, there's a _big_ jump in complexity from using python (2 or 3) and its stdlib vs. requiring a library. A script using only the stdlib is easy to distribute and get working on developer, ci, and production machines. Once an external library is required, I need machinery or scripts to manage or ensure presence of those dependencies.
#!/usr/bin/env nix-shell
#!nix-shell -i python -p python pythonPackages.pendulum ffmpeg
Even with simple shell scripts... it's so easy to invoke programs with GNU extensions and later find they fail on a co-workers macos machine. And I often have a shell.nix sitting right there that defines the complete dependency closure; very frustrating to not be able to use it.
Besides, for time zones, you can't do otherwise: it's not in the stdlib. So compared to pytz, it's easy.
Unrelated, but I highly recommand pex for script with dependancies. It will turn it to a one file bunddle of all required modules, and all you need on the server is the same oython version.
It should be in the stdlib really.
Hence we don't discourage people from using datetime, it's in the stdlib, and it's useful.
However, if you need time zones, either you code something yourself, in that case you are supposed to know what you are doing, or you look up the best libs for the job.
For the last part, no language have a perfect answer. It's an organic process. I've never met any tool solving it, not even intellij.
Maybe not in this exact case of dateutils vs. pendulum, but it's really easy to find outdated information on the web and struggle to confirm whether it's still the best answer.
I usually check the "awesome python list", ask on reddit and twitter, and then do some google foo. I select 3 packages and do some tests.
I got nothing better than that.
I don't think Django pulls in "pendulum" (someone please correct me if I'm wrong).
If Django isn't using it, I have to question how relevant "pendulum" actually is.
Personally when I use django, I also use pendulum at the same time. Django timezone management is limited to storing, retrieving and formatting time zone aware dates, but for:
- calculations
- moving from one time zone to another
- display of relative time
- parsing
- interval manipulations
Pendulum is making the job a breeze.
Let's put back things in context: most people don't need those features at all. And most people won't be affected by the bug in the article.
Use pendulum if you need it, which is quite rarely.
When I say people usually use libs like it, I mean people that have specific tasks that requires it. Few people actually do.
It's like asyncio, or "is python fast enough" and other things like that.
Because the issue is in the way datetime interacts with timezone objects (it assumes timezone objects are dumb and there's no co-dependency, which is incorrect), and fixing that would require changing the protocol, which would break existing libraries.