Fixing the mess 3.0 put me in

It’s become clear to me that 3.0 was a mistake, I should not have replaced pytz with zoneinfo, at least not in one go, a slower deprecation would have been better. Or maybe a fork. I lost track of why this library exist in the first place, I’m sorry about that.

Why tzlocal exists

tzlocal exists because there was no way to get the local timezone with pytz. In dateutil, you could, it had a method for that, with pytz, you HAD to know the local timezone name. So I made this library to get the local timezone name. However, I realized that some Unix installations did not have a local timezone configured, instead you had to use the /etc/localtime file. In that case, you couldn’t figure out the name, you could only return the anonymous timezone.

So, tzlocal returned pytz timezone objects, to deal with that.

The mess

Then came zoneinfo, and @agronholm needed a zoneinfo version of tzlocal. And I thought “Well, people are going to stop using pytz over time, so…”

However… on Unix (haven’t tried OS X yet) you can do zoneinfo.ZoneInfo(‘localtime’). So you don’t actually need tzlocal at all. And on Windows you can always find a zoneinfo name, so you don’t need tzlocal to return an object, just the zoneinfo name.

So switching tzlocal to return ZoneInfo objects actually never made sense. But that’s what happened. So the question now, is how to get out of the mess. And there are a few ways:

Option 1

• Release a 4.0 that deprecates the get_localzone() functions for get_localzone_name() functions (I did that and released it as 4.0b2), and move tzlocal to only look for a name.
• Support pytz users by releasing a pytz version (maybe without the deprecation) as 2.2.
• Drawback: 2.x is Python 2 compatible otherwise, so people on python 2 may have pinned tzlocal < 3, so not ideal.

Option 2

• Yank 3.x and 4.x, so people don’t install them by mistake
• Return tzlocal to pytz support and release it as 5.0 with the get_localzone_name() function for zoneinfo use. This would mean installing pytz even though you don’t need it.
• Drawback: People who switched to zoneinfo and didn’t pin the version will get breakage.

Option 3

• Yank 3.x and 4.x, and return tzlocal to pytz support, and release it as 2.2.
• Make a new library called , maybe, tzlocalname that returns the name of the local timezone.
• Drawback: People who switched to zoneinfo and didn’t pin the version will get breakage.

Option 4

• Release a 4.0 that deprecates the get_localzone() functions for get_localzone_name() functions (I did that and released it as 4.0b2), and move tzlocal to only look for a name, with removing the zoneinfo support in 5.0.
• Release a pytz version called pytzlocal
• Drawback: None that 3.0 didn’t already create.

Option 5

• Deprecate tzlocal completely
• Release tzlocalname to get the name
• Release pytzlocal to get a pytz object
• Drawback: None, I think?

Option 6

• Your suggestions here.

Please discuss!

[regebro]

4.0 released, so time to close this. Thanks for the feedback!

[pganssle]

Also, should get_localzone_name() return None or error out if no name is found?

I would recommend error, since almost certainly the consumers of such an API will be counting on a non-None value there.