Please Thank you for taking this discussion in a very productive direction, not everyone would respond as well to the situation you are in :) Drawback: None that 3.0 didn't already create.Release a pytz version called pytzlocal.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. Make a new library called, maybe, tzlocalname that returns the name of the local timezone.Yank 3.x and 4.x, and return tzlocal to pytz support, and release it as 2.2.Drawback: People who switched to zoneinfo and didn't pin the version will get breakage.This would mean installing pytz even though you don't need it. Return tzlocal to pytz support and release it as 5.0 with the get_localzone_name() function for zoneinfo use.Yank 3.x and 4.x, so people don't install them by mistake.Drawback: 2.x is Python 2 compatible otherwise, so people on python 2 may have pinned tzlocal Support pytz users by releasing a pytz version (maybe without the deprecation) as 2.2.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.So the question now, is how to get out of the mess. So switching tzlocal to return ZoneInfo objects actually never made sense. 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 you don't actually need tzlocal at all. on Unix (haven't tried OS X yet) you can do zoneinfo.ZoneInfo('localtime'). And I thought "Well, people are going to stop using pytz over time, so." Then came zoneinfo, and needed a zoneinfo version of tzlocal. So, tzlocal returned pytz timezone objects, to deal with that. In that case, you couldn't figure out the name, you could only return the anonymous timezone. However, I realized that some Unix installations did not have a local timezone configured, instead you had to use the /etc/localtime file. So I made this library to get the local timezone name. In dateutil, you could, it had a method for that, with pytz, you HAD to know the local timezone name. Tzlocal exists because there was no way to get the local timezone with pytz. I lost track of why this library exist in the first place, I'm sorry about that. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |