American time zones like CT, give error: ZoneInfoNotFoundError: 'No time zone found with key CT'

Question

Python 3.9 introduced the zoneinfo module:

The zoneinfo module provides a concrete time zone implementation to support the IANA time zone database as originally specified in PEP 615. By default, zoneinfo uses the system’s time zone data if available; if no system time zone data is available, the library will fall back to using the first-party tzdata package available on PyPI.

On my Ubuntu machine, it supports lots of time zones:

>>> from zoneinfo import ZoneInfo
>>> ZoneInfo("America/New_York")
zoneinfo.ZoneInfo(key='America/New_York')
>>> ZoneInfo("MST") # Mountain Standard Time
zoneinfo.ZoneInfo(key='MST')
>>> ZoneInfo("CET") # Central European Time
zoneinfo.ZoneInfo(key='CET')

However, it doesn't seem to support some time zones abbreviations used in North America like Central Time (CT), Central Standard Time (CST) or Pacific Standard Time (PST).

>>> ZoneInfo("CT")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key CT'
>>> ZoneInfo("CST")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key CST'
>>> ZoneInfo("PST")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key PST'

How can I get the right ZoneInfo objects for time zones like CT, CST or PST? Is the time zone database lacking? Does it depend on the operating system that I'm running?

Answer 1

There are issues with the abbreviations CT (Central Time), CST (Central Standard Time), PT (Pacific Time), and PST (Pacific Standard Time). Here are the main two:

• They do not identify a unique time zone. For example, CST could stand for Central Standard Time, but it could also stand for Cuban Standard Time or China Standard Time. The IANA database of time zones lists CST for all these areas.
• CST and PST are not appropriate during the summer, as most parts of the USA switch to daylight savings time during the period of the year that includes the summer. During the summer, the terms CDT (Central Daylight Time) and PDT (Pacific Daylight Time) should be used instead.

Central:

Instead of CT (CST during the winter or CDT during the summer), use US/Central or Canada/Central IANA identifier instead:

>>> from zoneinfo import ZoneInfo
>>> ZoneInfo("US/Central")
zoneinfo.ZoneInfo(key='US/Central')

Pacific:

Instead of PT (PST during the winter or PDT during the summer), use US/Pacific or Canada/Pacific instead:

>>> ZoneInfo("US/Pacific")
zoneinfo.ZoneInfo(key='US/Pacific')

Mountain:

For MT (MST during the winter and MDT during the summer), use US/Mountain for the areas that follow daylight savings time during the summer, and use America/Phoenix for the parts of Arizona that use MST all year round.

>>> ZoneInfo("US/Mountain")
zoneinfo.ZoneInfo(key='US/Mountain')
>>> ZoneInfo("America/Phoenix")
zoneinfo.ZoneInfo(key='America/Phoenix')

Note that Python does accept MST as a key. This identifier does not follow daylight savings time though, which you may not expect.

Eastern:

For ET (EST during the winter or EDT during the summer), use US/Eastern or Canada/Eastern:

>>> from zoneinfo import ZoneInfo
>>> ZoneInfo("US/Eastern")
zoneinfo.ZoneInfo(key='US/Eastern')

Note that Python does accept EST as a key. This identifier does not follow daylight savings time though, which you may not expect.

(Notice that parts of Arizona on the map represented by Phoenix don't observe Daylight Time)

Answer 2

Zoneinfo, pytz, and others use IANA time zones. You can find a complete list here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

In general, the abbreviations you specified are obsolete zones that should not be used. They only exist for backwards compatibility purposes.

In particular:

• EST, MST, and HST are defined here. They are fixed time zones with offsets of -5, -7, and -10 respectively. They do not have any DST rules.

• WET, CET, MET, and EET are defined here. They have offsets 0, +1, +1, and +2 respectively, and follow European DST rules, without regard to any specific country.

There are a few others, but none of them should be used.

You asked about CT, CST, and PST - these are not defined in the IANA data, and that's a good thing. Abbreviations are not identifiers.

As far as the recommended identifiers, that depends very much on the country and how far back you need to support. The current list of all time zones in active use within the USA (considering only states, not territories) is:

• America/New_York - Eastern time zone
• America/Chicago - Central time zone
• America/Denver - Mountain time zone
• America/Phoenix - Mountain time zone without DST, used in most of Arizona
• America/Los_Angeles - Pacific time zone
• America/Anchorage - Alaska time zone
• America/Adak - Aleutian time zone (far west isles of Alaska)
• Pacific/Honolulu - Hawaiian time zone

Note that I've chosen to use locality-based time zones, as this is the current best practice.

You also asked:

Does it depend on the operating system that I'm running?

Python uses IANA identifiers on all major operating systems. The choice of OS does not change the type of time zone ID you use with Python.

Answer 3

Per: https://docs.python.org/3/library/zoneinfo.html

The zoneinfo module does not directly provide time zone data, and instead pulls time zone information from the system time zone database or the first-party PyPI package tzdata

There are a number of utility methods you likely can call to help debug. Read that pages though as many of these methods come with caveats and/or warnings.

I might start with:

zoneinfo.available_timezones()

but that comes with the following:

Get a set containing all the valid keys for IANA time zones available anywhere on the time zone path. This is recalculated on every call to the function.

This function only includes canonical zone names and does not include “special” zones such as those under the posix/ and right/ directories, or the posixrules zone.

Caution This function may open a large number of files, as the best way to determine if a file on the time zone path is a valid time zone is to read the “magic string” at the beginning.

Note These values are not designed to be exposed to end-users; for user facing elements, applications should use something like CLDR (the Unicode Common Locale Data Repository) to get more user-friendly strings. See also the cautionary note on ZoneInfo.key.