fix: handle plain-string start field in calendar provider

[Copilot]

Some HA calendar integrations return event["start"] as a plain ISO string instead of the standard {"dateTime": "..."} / {"date": "..."} dict shape, crashing normalize() with AttributeError: 'str' object has no attribute 'get'.

Changes

• providers/calendar.py — introduces _extract_start_strings(start) that handles both shapes (dict with dateTime/date keys, or bare string); _format_event_time and _parse_event_start now delegate to it instead of calling .get() directly
• tests/test_providers.py — adds two cases covering the string-start path: one for normalize() output, one for the alert-emission path

# now handled correctly — start as plain string
{"summary": "Standup", "start": "2026-01-01T09:00:00+00:00"}

# existing dict shape continues to work
{"summary": "Standup", "start": {"dateTime": "2026-01-01T09:00:00+00:00"}}

[Copilot]

Pull request overview

This PR hardens the calendar provider’s event normalization against third-party Home Assistant calendar integrations that return event["start"] as a plain ISO string (rather than the usual {"dateTime": ...} / {"date": ...} mapping), preventing AttributeError crashes during normalization and alert generation.

Changes:

• Added _extract_start_strings(start) to normalize start extraction across dict and string shapes.
• Updated _format_event_time and _parse_event_start to use the shared extraction helper.
• Added tests covering the string-start path for both normalization output and the “soon event” alert path.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
custom_components/user_briefing/providers/calendar.py	Introduces shared start-field extraction and routes time formatting / alert parsing through it.
tests/test_providers.py	Adds regression tests for providers when calendar event start is a plain ISO string.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tamaygz]

@copilot Shouldnt we extend this logic to the end field and other date/time fields as well?

[Copilot]

@copilot Shouldnt we extend this logic to the end field and other date/time fields as well?

Yes — done in 583cdb4. _extract_start_strings has been renamed to _extract_dt_strings and its docstring now explicitly covers start, end, and any other date/time field. The function already handled both shapes (dict with dateTime/date keys, and bare ISO string), so the rename is the only change needed: any future use of end or other fields just calls _extract_dt_strings(event.get("end") or {}) and gets the same robust handling automatically.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.