-
-
Notifications
You must be signed in to change notification settings - Fork 23
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 non-pytz timezones #57
Comments
Looking at the issue, it might be nice to test that the library can deal with
Or at least there should be documentation about how to use these with the library. |
Whilst looking at the tests in the PR, I had initially considered updating the tests to use zoneinfo timezones instead of pytz ones, but indeed we probably want to clone those tests instead to ensure they work with either type. |
I am a bit confused about the zoneinfo module... It would need more reading for me. I will see. I think, it is good to support this and to drop pytz. So, if you have ideas about how to appoach it, it is welcome. Maybe I will try to create a PR for the code you showed in this issue. |
Apologies for the radio silence -- I got another quick look in, but the scope of the test failures was pretty wide and I wasn't really sure where to go from there. The zoneinfo calendar fixtures in your PR look like a good place to start. |
I switched to Gitlab-CI for tests. When #78 is merged, support for zoneinfo should be there from Python 3.7 on. |
@Terrance In Version 1.0.1b the handling if zoneinfo time zones is tested and implemented. |
I'm currently trying to write a program involving calendars, and the mix of dependencies I've got seem to fall into one or both of two categories: support for pytz timezones, and support for PEP-495 timezones (e.g. zoneinfo and dateutil).
From reading the discussion in pytz_deprecation_shim's documentation and toying with my existing dependencies, the latter seems to be the modern way to go, and works with the exception of this library --
convert_to_datetime()
makes the assumption that adatetime
instance'stzinfo
field is a pytz timezone, by use of itslocalize()
method. As I understand it, this call is not needed for PEP-495 timezone objects as it's specifically for transition folds (which thedatetime
class in Python 3.6+ handles natively, and dateutil backports with a subclass).To reproduce
Suggested implementation
Currently I'm making use of pytz_deprecation_shim and passing the shim wrappers to recurring-ical-events, which seems to work but produces deprecation warnings on use of the shim's
localize()
. This could be solved better if the library itself was aware of PEP-495 timezones by default, and only calledlocalize()
when encountering a pytz timezone that provides it.I'm happy to PR this, though I'm not sure the best way of detecting the type of timezone -- there are a few options:
hasattr(tz, "localize")
, but that will be incorrect for pytz_deprecation_shim if that's being used elsewhereisinstance(tz, pytz.BaseTzInfo)
, but that would require an ongoing dependency on pytz which wouldn't be needed otherwise; you'll also need a relatively recent pytz otherwisepytz.UTC
isn't an instance ofBaseTzInfo
localize()
The text was updated successfully, but these errors were encountered: