Can't start my Django if I set the version 2022.2:

Command: python manage.py produces the following output:

zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Asia/Hanoi'

If I set requirements version to pytz==2022.1 then it works fine.

Please advise.

Resolution by UN Economic and Social Council, 10th UN Conference on the Standardization of Geographical Names (2012).

Matches spelling adopted by IATA and ICAO.

In a dynamic deployment environment, sometimes it's needed to "warm" the library by preloading all the data files before the application starts. Would be great if the library had a single entry point for that, to have a shared, stable way of doing so.

the current version Time Zone Database is 2021e, so 2021c seems outdated. This might cause invalid UTC offsets like e.g.

from datetime import datetime
import pytz

>>> dt = datetime.fromisoformat('2046-05-31 22:00:00+00:00').astimezone(pytz.timezone("Europe/Paris"))
>>> print(dt)
2046-05-31 23:00:00+01:00
# should be 
# 2046-06-01 00:00:00+02:00

>>> print(pytz.__version__)
2021.3

from zoneinfo import ZoneInfo
>>> dt = datetime.fromisoformat('2046-05-31 22:00:00+00:00').astimezone(ZoneInfo("Europe/Paris"))
>>> print(dt)
2046-06-01 00:00:00+02:00

>>> import tzdata
>>> print(tzdata.IANA_VERSION)
2021e

Python 3.9.4 on Windows 10

We are observing an unexpected OverflowError from time.mktime. So far we're only able to reproduce within Github Actions.

I'm unsure if the issue is related to pytz. However, I thought it would make sense to open an issue here first to rule it out.

A minimally reproducible example of the issue is below:

import datetime
import time
import pytz
x = pytz.timezone('US/Pacific')
y = datetime.datetime(2017,5,26,15,30,16)
z = x.localize(y)
print(time.mktime(z.timetuple()))

The code above appears to work on Python 3.9 using pytz 2021.3 on OSX 11.6.1, Centos 7.9, Ubuntu 18.04 and macos-latest in Github Actions. However, it does not appear to work within ubuntu-latest on Github Actions. In all cases, Python and pytz are being sourced by conda.

An example log of the failure can be found here. The build configuration has been minimized as to only install Python 3.9 and pytz (latest).

A passing execution, on macos-latest, can be found here.

Please let me know if additional information would be helpful. I apologize if this issue is being opened on the wrong project, and if it instead would be better for python-dev. It does appear the issue has been noted with python-dev but closed on the assumption it was related to pytz.

Thank you for your time, and all your hard work on this foundational project.

I am confused by the following behavior:

>>> import pytz
>>> pytz.__version__
'2018.3'
>>> utc = pytz.timezone('UTC')
>>> la = pytz.timezone('America/Los_Angeles')
>>> isinstance(utc, pytz.tzinfo.BaseTzInfo)
False
>>> isinstance(la, pytz.tzinfo.BaseTzInfo)
True

Is this intended, and if so, why?

Thanks!

File "/usr/local/lib/python3.10/site-packages/timezone_field/init.py", line 1, in from timezone_field.fields import TimeZoneField File "/usr/local/lib/python3.10/site-packages/timezone_field/fields.py", line 11, in class TimeZoneField(models.Field): File "/usr/local/lib/python3.10/site-packages/timezone_field/fields.py", line 41, in TimeZoneField default_zoneinfo_tzs = [ZoneInfo(tz) for tz in pytz.common_timezones] File "/usr/local/lib/python3.10/site-packages/timezone_field/fields.py", line 41, in default_zoneinfo_tzs = [ZoneInfo(tz) for tz in pytz.common_timezones] File "/usr/local/lib/python3.10/zoneinfo/_common.py", line 24, in load_tzdata raise ZoneInfoNotFoundError(f"No time zone found with key {key}") zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Asia/Hanoi'

Hi, I'm having an AttributeError: module 'posixpath' has no attribute 'sep' because this if statement. I'm using python 3.10.4.

I'm not using pytz directly, but instead, I'm profiling a web app and that happens when I start the profiler (scalene) with scalene app.py and PyBabel calls pytz. If needed I can paste here the traceback.

However, after taking a look at the os module, indeed there isn't an os.path.sep attribute. But there is os.sep or os.pathsep. In this case, I think the most appropriate method would be the os.sep because it returns the OS path separator. If this is a real issue with pytz, I'm happy to provide PR to fix it.

Cheers

I'm trying to package your module as an rpm package. So I'm using the typical PEP517 based build, install and test cycle used on building packages from non-root account.

• python3 -sBm build -w
• install .whl file in </install/prefix>
• run pytest with PYTHONPATH pointing to sitearch and sitelib inside </install/prefix>

Here is pytest output:

+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-pytz-2021.3-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-pytz-2021.3-2.fc35.x86_64/usr/lib/python3.8/site-packages
+ /usr/bin/pytest -ra
=========================================================================== test session starts ============================================================================
platform linux -- Python 3.8.12, pytest-6.2.5, py-1.11.0, pluggy-1.0.0
rootdir: /home/tkloczko/rpmbuild/BUILD/pytz-release_2021.3/src
collected 41 items / 1 error / 40 selected

================================================================================== ERRORS ==================================================================================
________________________________________________________________ ERROR collecting pytz/tests/test_tzinfo.py ________________________________________________________________
pytz/tests/test_tzinfo.py:40: in <module>
    GMT = pytz.timezone('GMT')
../../../BUILDROOT/python-pytz-2021.3-2.fc35.x86_64/usr/lib/python3.8/site-packages/pytz/__init__.py:179: in timezone
    zone = _case_insensitive_zone_lookup(_unmunge_zone(zone))
../../../BUILDROOT/python-pytz-2021.3-2.fc35.x86_64/usr/lib/python3.8/site-packages/pytz/__init__.py:205: in _case_insensitive_zone_lookup
    _all_timezones_lower_to_standard = dict((tz.lower(), tz) for tz in all_timezones)  # noqa
E   NameError: name 'all_timezones' is not defined
========================================================================= short test summary info ==========================================================================
ERROR pytz/tests/test_tzinfo.py - NameError: name 'all_timezones' is not defined
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
============================================================================= 1 error in 1.64s =============================================================================

Would be great to have a single "base" class for all errors that could be raised by the library.

Looking at https://github.com/stub42/pytz/blob/master/src/pytz/exceptions.py, there are two base classes at the moment: UnknownTimeZoneError and InvalidTimeError.

Without a guaranteed single base class, a package upgrade may add new error types, without call-sites being updated about the change.

👋 Hi! New contributor here. I'm updating the typing stubs for pytz in typeshed (PR#3393), specifically adding FixedOffset's typing. I'm unsure about the kwarg though, _tzinfos.

Here's the line I've put in typeshed. @stub42 Can you confirm the typing of _tzinfos (and, of course, let me know if the other types are wrong). The typeshed tests run, and it looks right to me... but I don't know pytz well enough. Thanks!

On Debian-based systems (including Ubuntu) pytz is patched to use the tzdata information from the system. That allows updating tzdata without needing to update pytz every time.

The superset of all_timezones and common_timezones is hard-coded in the pytz release (in pytz/__init__.py). When tzdata adds a timezone or renames one (e.g. Ubuntu bug #1995864), pytz needs to be updated.

pytz should evaluate the available timezones on the system to work with future tzdata updates.

Bug-Ubuntu: https://launchpad.net/bugs/207604

For the better part of a day I've been trying to properly calculate the number of hours in a given day using Python and pytz. I have significant experience doing date and time calculations, so this should be a simple task. However, I feel like I am being blocked at every exit.

Please consider the following code:

from datetime import datetime, timedelta
from pytz import timezone

# Set some things up
format = "%Y-%m-%d %H:%M:%S %Z%z"
tz_local = timezone('CET') #Europe/Stockholm
tz_utc = timezone('UTC')

# Set up a date just before the switch from winter to summer time
original = datetime(2022, 3, 25, 13, 11, 25, tzinfo = tz_local)
print(original.strftime(format))
# Create the same date in the world of UTC, where date calculations are easy as pie
redating = datetime(original.year, original.month, original.day, tzinfo = tz_utc)
# Add a week to the date
redating = redating + timedelta(days = 7)
# Create new date+time, with the original time, in the original timezone
output = datetime(redating.year, redating.month, redating.day, original.hour, original.minute, original.second, original.microsecond, tzinfo = tz_local)
print(output.strftime(format))
# Convert to UTC and back again.... (!?)
output = output.astimezone(tz_utc).astimezone(tz_local)
print(output.strftime(format))

The output is:

2022-03-25 13:11:25 CET+0100
2022-04-01 13:11:25 CET+0100
2022-04-01 14:11:25 CEST+0200

I know there have been discussions regarding whether CET should, or should not, have a fixed offset from UTC.

I am working under the understanding that:

• CET does NOT have a fixed offset from UTC - it observes summer and winter time.
• CEST is not an actual timezone, it is still CET - but during the summer.

Since I am someone who is used to dealing with the complexities at hand, and live in a country that observes CET you should absolutely not listen to me, because who know - I might just be full of it. Instead, you should listen to the large number of verifiable sources, online and offline, that claim the same, giving these statements at least some weight. Also, since pytz does not make a CEST timezone available, it would seem we are in agreement.

Regardless of correctness, it seems quite schizophrenic that I am getting CET from datetime(), but CEST after converting to UTC and back.

The output I would expect from this program is:

2022-03-25 13:11:25 CET+0100
2022-04-01 13:11:25 CEST+0200
2022-04-01 13:11:25 CEST+0200

So, in light of the discussions I've seen on the topic of what CET really is, I decided to go ahead and switch tz_local to Europe/Stockholm - a location-based timezone which, according to those discussions, should always observe DST if applicable.

After this, I get the following output:

2022-03-25 13:11:25 LMT+0053
2022-04-01 13:11:25 LMT+0053
2022-04-01 14:18:25 CEST+0200

This output made me faceplant the keyboard, demand comfort from my wife, and undertake several therapy sessions at the local pub.

Sweden, including Stockholm, like most European countries, observe CET. I know we are seen as quite backward at times here in Sweden, but I assure you that LMT+0053 is just too weird, even for us.

It may very well be that I am completely wrong or that I am doing things completely wrong. If this is the case, then I beg your forgiveness for wasting your time and humbly ask to be corrected. If, however, I am correct - it seems there is a bug in datetime() where it does not correctly return dates that fall within CEST as such, as well as a bug in pytz where it returns incorrect tzinfo for Europe/Stockholm.

I understand that the behavior of datetime() does not fall on pytz to dictate. But perhaps, given pytz popularity in the date- and time-loving python subcommunity, you might have some pull with the in-crowd.

All the best.

"Europe/Kiev", "Europe/Zaporozhye" are to be changed into "Europe/Kyiv", "Europe/Zaporizhzhia" respectively

https://phabricator.wikimedia.org/T149523

While most timezone classes share a BaseTzInfo class, _FixedOffset does not. Functionally it doesn't really make a difference, but with stricter type checking it can become troublesome. Some interfaces from third-party projects specify BaseTzInfo within type annotations where _FixedOffset should also work.

Would you be open to a change that just replaces class _FixedOffset(datetime.tzinfo): with class _FixedOffset(BaseTzInfo):?

Some browsers have different names of timezones: in Ukrainian manner (Europe/Kyiv) and in russian manner (Europe/Kiev).

Could you please track both (Europe/Kyiv) and (Europe/Kiev) to fix the changes between different browsers ?

Thanks you.

Would there be any interest in a PR to add typing for mypy compliance? The main benefits are better IDE integration and improved static type checking on projects that use pytz

Effort is pretty minimal, mypy only raises 14-18 errors currently, depending on the python version.

A stubs repo already does exist: much of that could likely https://github.com/python/typeshed/tree/master/stubs/pytz/pytz

Type hinting is quite easy in python 3.6+. Not sure how long compatibility for python 2.7/3.5 (seen in pipelines) is intended for but that's doable too, just less elegant https://mypy.readthedocs.io/en/stable/cheat_sheet.html