bug: Error in algorithm: tzinfo expected to be known.

[iprak]

Describe the bug

I created a new repetitive event and have been hitting this exception. The event is in my default time zone (GMT-06:00 Central - Chicago Time).

AssertionError: Error in algorithm: tzinfo expected to be known.    
	assert tzinfo is not None, "Error in algorithm: tzinfo expected to be known."  
File "/usr/lib/python3.8/site-packages/recurring_ical_events.py", line 52, in convert_to_datetime    
	span_start = convert_to_datetime(span_start, self.tzinfo)  
File "/usr/lib/python3.8/site-packages/recurring_ical_events.py", line 228, in within_days   
	for repetition in event_repetions.within_days(span_start_day, span_stop_day):  
File "/usr/lib/python3.8/site-packages/recurring_ical_events.py", line 365, in between    
	events = recurring_ical_events.of(calendar).between(start_time, end_time)

To Reproduce

ICS file

I do not have an ics file at this time.

Expected behavior

Console output

Version:

Additional context

Suggested implementation

• add an ICS file, example:
  

  python-recurring-ical-events/test/calendars/issue-15-duplicated-events.ics

  Line 1 in f4a90b2

  BEGIN:VCALENDAR

• add a test, example:
  

  python-recurring-ical-events/test/test_issue_15.py

  Line 21 in f4a90b2

  def test_sequence_is_not_present(calendars):

• implement the test
• fix the test

[niccokunzmann]

Hi, thanks. Can you post some Python code to create the event? We can fix it best if we know how to create the error.

[iprak]

Currently I don't have access to replicate stand alone. This was happening in an app running inside AppDomain addon in HomeAssistant. But by adding some logging code , I traced this down the failure to single and multiple full day events.

I added this code in the middle on the app. The first entry does not have timezone and results in the exception.

	calendar = icalendar.Calendar.from_ical(feed_text)

	for event in calendar.walk():
		if isinstance(event, icalendar.cal.Event):
			#self.log(event)
			self.log(f'{event["DTSTART"].dt} {event["SUMMARY"]}')

2021-03-11 06:19:49.347046 INFO Reminders: 2021-03-19 No school
2021-03-11 06:19:49.369978 INFO Reminders: 2021-03-10 19:00:00-06:00 journal

I adjusted the same block to populate tzinfo and locally resolved the error:

        for event in calendar.walk():
            if isinstance(event, icalendar.cal.Event):
                #self.log(event)

                event_start_dt = event["DTSTART"].dt
                if isinstance(event_start_dt, datetime):
                    self.log(f'{event_start_dt} {event["SUMMARY"]}  {event_start_dt.tzinfo}')
                elif isinstance(event_start_dt, date):
                    self.log(f'{event_start_dt} {event["SUMMARY"]} dateOnly')
                    event_start_dt=datetime(
                        year=event_start_dt.year,
                        month=event_start_dt.month,
                        day=event_start_dt.day,
                        tzinfo=localTZ
                    )
                    self.log(f'{event_start_dt} ')
                    event["DTSTART"].dt = event_start_dt

[niccokunzmann]

I think, we are getting closer to reproducing it. Can you tell me the contents of

within_days(span_start_day, span_stop_day)

And print instead of just dtstart of the event the whole event.to_ical()? That should be enough to reproduce it.

[iprak]

This is the scrubbed output of event.to_ical(). I don't have access to modify recurring_ical_events itself.

b'BEGIN:VEVENT\r\nSUMMARY:Something\r\nDTSTART;TZID=America/Chicago:20210329T190000\r\nDTEND;TZID=America/Chicago:20210329T191500\r\nDTSTAMP:20210320T110701Z\r\nnRECURRENCE-ID;TZID=America/Chicago:20210329T190000\r\nSEQUENCE:3\r\nCREATED:20210310T151734Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20210320T110656Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Something\r\nDTSTART;TZID=America/Chicago:20210315T190000\r\nDTEND;TZID=America/Chicago:20210315T191500\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:3\r\nRRULE:FREQ=DAILY\r\nCREATED:20210310T151734Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20210320T110656Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Pickup\r\nDTSTART;TZID=America/Chicago:20210309T151000\r\nDTEND;TZID=America/Chicago:20210309T151500\r\nDTSTAMP:20210320T110701Z\r\nrSEQUENCE:1\r\nRRULE:FREQ=WEEKLY;UNTIL=20210316T045959Z;INTERVAL=1;BYDAY=TU,WE,TH,FR;WKST\r\n =SU\r\nCREATED:20210306T114321Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20210319T004039Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Pickup\r\nDTSTART;TZID=America/Chicago:20210316T151000\r\nDTEND;TZID=America/Chicago:20210316T151500\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:1\r\nRRULE:FREQ=WEEKLY;UNTIL=20210622T045959Z;INTERVAL=1;BYDAY=TU,WE,TH,FR;WKST\r\n =SU\r\nEXDATE;TZID=America/Chicago:20210528T151000\r\nEXDATE;TZID=America/Chicago:20210402T151000\r\nEXDATE;TZID=America/Chicago:20210401T151000\r\nEXDATE;TZID=America/Chicago:20210331T151000\r\nEXDATE;TZID=America/Chicago:20210330T151000\r\nEXDATE;TZID=America/Chicago:20210319T151000\r\nCREATED:20210306T114321Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20210319T004039Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Drop off\r\nDTSTART;TZID=America/Chicago:20210309T080000\r\nDTEND;TZID=America/Chicago:20210309T080500\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:3\r\nRRULE:FREQ=WEEKLY;UNTIL=20210316T045959Z;INTERVAL=1;BYDAY=TU,WE,TH,FR;WKST\r\n =SU\r\nCREATED:20210306T114249Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20210319T004035Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Drop off\r\nDTSTART;TZID=America/Chicago:20210316T080000\r\nDTEND;TZID=America/Chicago:20210316T080500\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:3\r\nRRULE:FREQ=WEEKLY;UNTIL=20210622T045959Z;INTERVAL=1;BYDAY=TU,WE,TH,FR;WKST\r\n =SU\r\nEXDATE;TZID=America/Chicago:20210528T080000\r\nEXDATE;TZID=America/Chicago:20210402T080000\r\nEXDATE;TZID=America/Chicago:20210401T080000\r\nEXDATE;TZID=America/Chicago:20210331T080000\r\nEXDATE;TZID=America/Chicago:20210330T080000\r\nEXDATE;TZID=America/Chicago:20210319T080000\r\nCREATED:20210306T114249Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20210319T004035Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Full Day\r\nDTSTART;VALUE=DATE:20210329\r\nDTEND;VALUE=DATE:20210403\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:0\r\nCREATED:20210312T122050Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20210312T122050Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:TRANSPARENT\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Full Day\r\nDTSTART;VALUE=DATE:20210528\r\nDTEND;VALUE=DATE:20210529\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:0\r\nCREATED:20210312T122012Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20210312T122012Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:TRANSPARENT\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Full Day\r\nDTSTART;VALUE=DATE:20210426\r\nDTEND;VALUE=DATE:20210427\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:0\r\nCREATED:20210312T121948Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20210312T121948Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:TRANSPARENT\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:zoom\r\nDTSTART:20201113T141500Z\r\nDTEND:20201113T143000Z\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:0\r\nCREATED:20201113T154536Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20201113T154536Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Music\r\nDTSTART;TZID=America/Chicago:20200918T120000\r\nDTEND;TZID=America/Chicago:20200918T121500\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:1\r\nRRULE:FREQ=WEEKLY;UNTIL=20201106T055959Z;BYDAY=FR\r\nEXDATE;TZID=America/Chicago:20201023T120000\r\nCREATED:20200915T145446Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20201102T000022Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Art\r\nDTSTART;TZID=America/Chicago:20200915T120000\r\nDTEND;TZID=America/Chicago:20200915T121500\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:1\r\nRRULE:FREQ=WEEKLY;UNTIL=20201103T055959Z;BYDAY=TU\r\nCREATED:20200915T115734Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20201102T000018Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Gym\r\nDTSTART;TZID=America/Chicago:20200917T113000\r\nDTEND;TZID=America/Chicago:20200917T114500\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:1\r\nRRULE:FREQ=WEEKLY;UNTIL=20201105T055959Z;BYDAY=TH\r\nCREATED:20200915T124057Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20201102T000012Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:zoom\r\nDTSTART;TZID=America/Chicago:20200915T081500\r\nDTEND;TZID=America/Chicago:20200915T083000\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:1\r\nRRULE:FREQ=WEEKLY;UNTIL=20200923T045959Z;BYDAY=FR,MO,TH,TU,WE\r\nEXDATE;TZID=America/Chicago:20200916T081500\r\nCREATED:20200915T115822Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20200916T120239Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'
b'BEGIN:VEVENT\r\nSUMMARY:Jenkins\r\nDTSTART:20200912T023000Z\r\nDTEND:20200912T024500Z\r\nDTSTAMP:20210320T110701Z\r\nSEQUENCE:0\r\nCREATED:20200912T022656Z\r\nDESCRIPTION:\r\nLAST-MODIFIED:20200912T022656Z\r\nLOCATION:\r\nSTATUS:CONFIRMED\r\nTRANSP:OPAQUE\r\nEND:VEVENT\r\n'

[rtphokie]

I'm consistently tripping up on this whenever sending a timezone aware datetime, for example:

 start_date = datetime.now(pytz.utc)
 end_date = start_date + datetime.timedelta(days=30)
 calendar = icalendar.Calendar.from_ical(ical_string)
 events = recurring_ical_events.of(calendar).between(start_date, end_date)

produces this error:

 File ".../lib/python3.9/site-packages/recurring_ical_events.py", line 52, in convert_to_datetime
    assert tzinfo is not None, "Error in algorithm: tzinfo expected to be known."
 AssertionError: Error in algorithm: tzinfo expected to be known.

[asimonson1125]

I reproduced this issue by assigning a timezone to datetime like so:
datetime.now().astimezone()
It seems recurring_ical assumes that there is no tzinfo and throws that error when there is.

[niccokunzmann]

There is PR #63 which reproduces this behavior.

[niccokunzmann]

A fix is deployed from version v0.2.3b on.