@pganssle do you want me to review this?

@mariocj89 I still need to backport the tests, but you are welcome to review it. I expect in the long run we'll want to consolidate some of the logic around tzstr and tzrange and some of these custom rule representations built into the TZif parser (for the extended version 2 support that allows specifying a POSIX string), but I don't expect to overhaul anything else.

Also I believe some documentation changes will be necessary before we can merge this as well.

OK, I'll take a look once all is ready.

So @mariocj89 I suppose this is really the only remaining blocker for dropping support for Python 2?

Dropping support for Python 2 would mean we could get into in-place typing info and all the new fun stuff right :)?

Given this has been open for ages, should I try to prioritize this MR, open a new MR and see if we can get somewhere within the next few months?

@Jorricks this is indeed blocking most of the progress in the repo. If you have cycles to work on this we could drop Python 2 after we land and release this. @pganssle has been wanting to work on this for a long time but was not able to commit time to it.

+1

Hi @mariocj89,
I'm attempting to start but I am missing some context. Could you help me out answering these questions :)?

1. How is this effort blocking the Python2 removal/deprecation effort?
2. If I understand correctly, the idea of this MR is to back port a copy of zoneinfo (that is only available in Python3.9+) into this application which is compatible with the current tzinfo class right?
3. Is the idea to implement this feature Python3.7+ or should it be Python2 compatible? Mostly asking because I'd like to add type hints already :).

How is this effort blocking the Python2 removal/deprecation effort?

Without this change users in 2.7 will not get tz upgrades. This splits the tzdata from the package, allowing users to stay in an old version of the package but still get tzdata upgrades.

If I understand correctly, the idea of this MR is to back port a copy of zoneinfo (that is only available in Python3.9+) into this application which is compatible with the current tzinfo class right?

Correct

Is the idea to implement this feature Python3.7+ or should it be Python2 compatible? Mostly asking because I'd like to add type hints already :).

Needs to work for py2, so no type hints :).

How is this effort blocking the Python2 removal/deprecation effort?

Without this change users in 2.7 will not get tz upgrades. This splits the tzdata from the package, allowing users to stay in an old version of the package but still get tzdata upgrades.

If I understand correctly, the idea of this MR is to back port a copy of zoneinfo (that is only available in Python3.9+) into this application which is compatible with the current tzinfo class right?

Correct

Is the idea to implement this feature Python3.7+ or should it be Python2 compatible? Mostly asking because I'd like to add type hints already :).

Needs to work for py2, so no type hints :).

Now it completely makes sense! Thanks.

@mariocj89 to improve visibility on the progress & smoothen the process a little. Can we open a new branch containing this work so far?
We can just keep using this topic to keep track of everything that remains to be done so far I suppose.

I was diving a bit further (as I want to make sure I understand the full context before making changes) and was wondering the following:
During the building of the python-dateutil wheel, we package the dateutil-zoneinfo.tar.gz. Could(/Should?) this then also be replaced with a slim version of tzdata?

@pganssle do you have some time to guide @Jorricks through this change please?

@pganssle are you still actively working on getting this change merged?

Unfortunately I don't have the time anymore to work on this and made zero progress anyway. So I don't think anyone is working on this.

The code is very complex and you are only doing this for python 2 users. Given that reached end of life years ago, I'm not to enthusiastic to work on this anyway.

Made a lot of progress on this at the sprints, but I don't think I'm going to quite get there today. I believe the main things left to do are:

1. Documentation of the changes
2. Test the tzfile with V1 data
3. Maybe adjust the repr to treat key/filename a bit better
4. Test the situation where only slim tzdata is installed

Hey @pganssle, you said that this PR "is really not that hard for a motivated individual to finish". After two years since my last comment, I think I've become motivated enough :D

I've started by rebasing this branch against master to get rid of conflicts: https://github.com/kytta/dateutil/compare/new_tzfile. You can reset your branch to mine, if you wish.

However, I am kind of stuck on the list of "things left to do", so maybe you can comment on some things:

2. Test the tzfile with V1 data

I assume this means that V2 (and V3) tests are ready? If so, where can I find them? I am a bit lost looking at huge test_tz.py and test_tzfile.py... 😅

Also, does this still mean that it would be enough to backport https://github.com/pganssle/zoneinfo/blob/666d80c27bda69541130758bbc7f1c9e035f79a0/tests/test_zoneinfo.py?

3. Maybe adjust the repr to treat key/filename a bit better

Do you mean tzfile.__repr__ or something else?

4. Test the situation where only slim tzdata is installed

I guess I know how to do this in GitHub Actions, but do you have guidance on how to enable developers to test this, too?

I will take my time to properly understand the changes in this PR, so no rush with your reply :)