[BUG] main branch failing, timezone name identification way too unstable

[niccokunzmann]

Describe the bug

The main branch is failing. The tests are those that try to identify the timezone id from dateutil timezones.

To Reproduce

See

• Exception No module named 'icalendar.timezone.equivalent_timezone_ids_result' #779
• [BUG] timezone definitions keep changing but are assumed static #776
• Test failure on Fedora with 6.1.0 #763.

Expected behavior

It would be nice to be able to identify timezones but as #776 shows, this is not trivial.
I think, that this should not be part of this package. We can generate timezones from actual timezone objects.
For now, the changes and assumptions make the tests fail and cause confusion.

I am wondering how to go on with this.

Possible fixes

• Disable the dateutil tests to find out which timezone id is used.
• Change the timezone identification to be more dynamic, based on the local installation (maybe still problematic)
• Remove the complex timezone identification fully - we can only claim easy compatibility to zoneinfo and pytz because they have a name
• create a separate package that handles timezone identification and link to it in the documentation
• allow passing an optional timezone name
• generate a timezone with a custom name if required.
• change the way timezone names for unknown timezones are generated and use the timezone objects to generate the timezones instead of the indirect way of using the timezone id.

Complexity

The timezone database differs on operating systems. Updates to timezones in the past are still issued. We have this complexity:

• OS
• timezone database/source: OLSON, iana, icalendar.Timezone
• timezone implementation/source pytz, zoneinfo, dateutil
• timezone database version

With this complexity, I suggest that identifying the name of the timezone is out of scope of this package. It is way too complex, an edge case (automatic generation of VTIMEZONE components).

Suggested Fix

I would suggest to generate the timezones from the timezone objects found in datetimes in the icalendar.Calendar. There is no need to go the indirect way of identifying the name first. However, should we know the name, we should use it (pytz, zoneinfo). I think, I added that feature because it was easy to test. I hope, removing this will help keep the package small and more stable.

I would be grateful to hear your thoughts on this.