This adds generating VTIMEZONE components from tzinfo objects

[niccokunzmann]

Fixes #722

Add icalendar.Timezone.from_tzinfo(ZoneInfo('Europe/Berlin')).

• check that transition times are computed properly for pytz
  Result: This is really tricky. I do not know why pytz does not converge or why it is weird around the transition times.
• create Calendar.add_missing_timezones
• check with actual transition times
  Two tests check this. When we parse a calendar, at least we get the right transition times in pytz and zoneinfo.
• issue for test_deep_copies_are_equal[issue_722_timezone_transition_ambiguity.ics-zoneinfo]
• remove todos

[coveralls]

Pull Request Test Coverage Report for Build 11770019396

Details

• 213 of 228 (93.42%) changed or added relevant lines in 8 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.2%) to 97.329%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/icalendar/cal.py	91	94	96.81%
src/icalendar/tests/conftest.py	6	9	66.67%
src/icalendar/timezone/provider.py	5	8	62.5%
src/icalendar/tests/test_issue_722_generate_vtimezone.py	95	101	94.06%

Totals
Change from base Build 11763222108:	-0.2%
Covered Lines:	3784
Relevant Lines:	3887

---

💛 - Coveralls

[niccokunzmann]

I run a bit into an issue here.

I can generate them successfully for zoneinfo/dateutil.
However, when I use pytz, I run into a strange error (VTIMEZONE component != VTIMEZONE component)

pytz -> VTIMEZONE -> pytz -> VTIMEZONE

changes the transition times.

Here VTIMEZONE == VTIMEZONE

zoneinfo -> VTIMEZONE -> dateutil -> VTIMEZONE

Since these yield the same result (VTIMEZONE == VTIMEZONE):

pytz -> VTIMEZONE
zoneinfo -> VTIMEZONE

I conclude that VTIMEZONE -> pytz is actually a bit problematic. I will check this. In this case, icalendar had a bug around the transition day that the time was moved a little. e.g.

• Europe/Berlin transitions at 3:00am/2:00am and our pytz implementation turns it into 4:00/0:00
• Amerika/New_York transitions at 3:00am/1:00am and our pytz implementation turns it into 4:00/0:00
• Asia/Singapore transitions at 19820101T000000 and our pytz implementation turns it into 19820101T003000 = +30min

Next steps:

• isolate the cause of the difference
• fix the mistake if it is ours

So, in case I cannot fix this and you depend on pytz, I still recommend that you upgrade

[niccokunzmann]

I think, the interface I would like to use is this one:

Calendar().add_missing_timezones()

This will then add all the missing timezones automatically to the calendar.

[stevepiercy]

LGTM, except for one param description.

[niccokunzmann]

The pytz parsing seems to fail when we check two calendars for equality.

   def assert_equal(actual_value, expected_value):
        """Make sure both values are equal"""
>       assert actual_value == expected_value
E       AssertionError: assert VCALENDAR({},...TE-TIME'}))})) == VCALENDAR({},...TE-TIME'}))}))
E         
E         Use -v to get more diff

src/icalendar/tests/test_equality.py:33: AssertionError
---------------------------- Captured stdout setup -----------------------------
example file: issue_722_timezone_transition_ambiguity.ics

[stevepiercy]

A few grammar fixes, and comments.