-
-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for "zic -b slim" tzfiles (default format since tz 2020b) #48
Comments
@diabonas I am not a maintainer of this, but I think @stub42 has said in the past that he doesn't plan to support version 2+ files. In Python 3.9, we added the Though I know @stub42 has mentioned before the possibility of |
We're aware of zoneinfo, and this new python 3.9 feature is a source of happiness for distro packagers. I did check the reproducer to see if zoneinfo was buggy the same way and was happy to discover it was not.
I agree. stdlib builtins are always good to rely on. This bug report merely hopes to propose that for the dozens of packages that are not yet ported, and which force the distro to continue to provide pytz, some solution is available to allow tzdata to use slim files. The alternative is of course to vendor fat ones into pytz, resulting in old timezone info inconsistent with the system... this is non-ideal. |
Probably the most prudent option for Arch Linux is to deploy Yes, the upstream default has changed to use
Why do you think it would be old and inconsistent? In any case, this is another manifestation of #31, which @stub42 said is basically a wontfix: #31 (comment) |
Rather than devendoring and revendoring, we would probably just remove the devendoring routine... If it is WONTFIX, then I guess it is what it is. I guess we'll see how projects adapt and migrate, and stick with fat tzfiles for now. |
The plan is for pytz to start using Python 3.9 zoneinfo and the backports, which should provide support for Python 3.6+. Python 2.4 -> 3.5 will be stuck requiring 'fat' files (which is fine, because that is what the old deployments have). Hopefully I or someone can prove @pganssle wrong and it can be fully backwards-compatible. If we can't get at least a mostly backwards-compatible version using Py3.9 zoneinfo, then we need a new pytz deprecation plan or embed a modified version of the Py3.9 code. |
To be clear, you can write a version of Making a version of |
I'm sure keeping pytz's API and output identical to its current behavior will be fine and no one is going to complain. :) Getting support for slim tzinfo files by hooking into zoneinfo's parser and the related infrastructure to search for system or pypi tzdata, while making no other changes, would still be a plus in my book. Additional changes could be added as a follow-up, if deemed practical. |
Yes, being backwards and forwards compatible would be a benefit only if the intention was to continue supporting Even if It's definitely a net positive if |
Is there an ETA for when this is implemented? We are having some issues after 2038 and would very much like to see these files supported. Is there a workaround for this we can apply in the meantime? |
tz switched the default format from
zic -b fat
tozic -b slim
in the 2020b release. Thetzfile.py
parser in this project currently does not support this file format and silently chokes on tzfiles generated by the latest tz version, leading to incorrecttzinfo
Python objects that are just using the default UTC time. To future-proof against the Y2038 problem, it would be great if pytz could support the new 64-bit only file format thatzic -b slim
produces.Downstream Arch Linux bug report: FS#68150. Note that Arch patches pytz to use the system timezone database, so this problem doesn't currently appear in a default installation of pytz, which comes bundles with tzfiles generated by an older version of tz. Regardless it would be good to support to add the new file format for the reason outlined above.
The text was updated successfully, but these errors were encountered: