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?

CodePudding user response：

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.
• They may only be appropriate during the summer or the winter, that is, during daylight savings time or not. For example, Central Standard Time is not the appropriate designator to use during daylights savings times, instead, CDT (Central Daylight Time) is.

Central:

Instead of CT or CST or CDT, use US/Central or Canada/Central IANA identifier instead:

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

Pacific:

Instead of PT, PST or PDT, use US/Pacific or Canada/Pacific instead:

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

Mountain:

For Mountain Standard Time (MST or MDT), you can use MST or US/Mountain or Canada/Mountain:

>>> ZoneInfo("MST")
zoneinfo.ZoneInfo(key='MST')

Eastern

For Eastern Standard Time (ET or EST or EDT), use EST or US/Eastern or Canada/Eastern:

>>> from zoneinfo import ZoneInfo
>>> ZoneInfo("EST")
zoneinfo.ZoneInfo(key='EST')

CodePudding user response：

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.

CodePudding user response：

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?

No, IANA identifiers are used on all major operating systems.