Introduction

Yes. pytz ships with lists of timezone names, and the most commonly used one is pytz.all_timezones. Once you know where that list lives, you can use it for validation, user dropdowns, and conversions between UTC and local time.

Use pytz.all_timezones

The full timezone list is available as a plain Python list:

1import pytz
2
3print(len(pytz.all_timezones))
4print(pytz.all_timezones[:10])

Each value is an IANA timezone name such as America/New_York or Europe/London. That is the same naming scheme most timezone-aware systems use.

If you want to print the whole list:

1import pytz
2
3for name in pytz.all_timezones:
4    print(name)

This is the direct answer to the title question.

Use Smaller Lists When The Full Set Is Too Large

The complete list is useful, but it can be longer than you want for a user-facing dropdown. pytz also exposes common_timezones, which is usually easier to present in an application UI.

1import pytz
2
3print(len(pytz.common_timezones))
4print(pytz.common_timezones[:10])

If you need country-specific timezones, there is also country_timezones:

1import pytz
2
3print(pytz.country_timezones["us"])
4print(pytz.country_timezones["gb"])

This is useful when your form first asks for a country and only then asks for a timezone.

Turn A Timezone Name Into A Real Timezone Object

The list itself is only the starting point. You usually take one of those names and convert it into a timezone object with pytz.timezone(...).

1import pytz
2from datetime import datetime
3
4utc_now = datetime.now(pytz.utc)
5eastern = pytz.timezone("America/New_York")
6tokyo = pytz.timezone("Asia/Tokyo")
7
8print(utc_now.astimezone(eastern))
9print(utc_now.astimezone(tokyo))

This is the normal workflow in real applications: store or select an IANA name, then use it to localize or convert datetimes.

If you only need UTC, pytz.utc is also available directly, but for user-facing timezone choices you almost always want one of the named entries from the timezone lists rather than a hard-coded offset.

Validate User Input Against The List

One practical use for the timezone list is input validation. If a user or API client sends a timezone string, check that it exists before trying to use it.

1import pytz
2
3def is_valid_timezone(name: str) -> bool:
4    return name in pytz.all_timezones_set
5
6
7print(is_valid_timezone("Europe/London"))
8print(is_valid_timezone("Mars/Olympus"))

Notice the use of all_timezones_set. Membership checks against a set are faster than checking the full list repeatedly.

Be Careful Around DST Transitions

Timezone names are easy to list, but using them correctly still requires care. Daylight saving transitions can create ambiguous or nonexistent local times, so timezone-aware applications should test scheduling behavior near those boundaries.

With pytz, localizing naive datetimes is different from simple tzinfo= assignment for many use cases. A common pattern is:

1import pytz
2from datetime import datetime
3
4eastern = pytz.timezone("America/New_York")
5naive = datetime(2026, 3, 11, 9, 30, 0)
6aware = eastern.localize(naive)
7
8print(aware)

That is separate from listing the timezone names, but it matters because developers often find the list first and then immediately start building conversions.

Common Pitfalls

• Using the full timezone list in a user interface when a smaller curated list would be more practical.
• Validating timezone names with list membership over and over instead of using all_timezones_set.
• Assuming every country maps to exactly one timezone.
• Treating a timezone name as enough without understanding daylight saving transitions.
• Mixing naive datetimes with timezone-aware ones after selecting a pytz timezone.

Summary

• 'pytz.all_timezones gives you the full list of timezone names.'
• 'pytz.common_timezones and country_timezones are often better for application-facing workflows.'
• Convert a timezone name into an object with pytz.timezone(...).
• Use the list or set forms for validation, and handle localization carefully around DST boundaries.