Julian Pawlowski a010ccd290 fix(interval_pool): use tz-aware datetime comparison at resolution boundary ... RESOLUTION_CHANGE_ISO was a naive ISO string ("2025-10-01T00:00:00"). _split_at_resolution_boundary compared it against timezone-aware interval strings via plain string ordering, which is unreliable when the strings carry different UTC offsets (e.g. +02:00 vs +00:00). More critically, the naive string was then split into ranges such as ("...", "2025-10-01T00:00:00") which were parsed back to naive datetime objects in fetch_missing_ranges. When routing.py then compared those naive objects against the tz-aware boundary datetime, Python raised TypeError: can't compare offset-naive and offset-aware datetimes. Fix: - Remove RESOLUTION_CHANGE_ISO; derive the boundary ISO string at runtime from RESOLUTION_CHANGE_DATETIME.isoformat(), which produces the UTC-normalised string "2025-10-01T00:00:00+00:00". - Rewrite _split_at_resolution_boundary to parse each range's start/end to datetime objects, normalise any defensively-naive values to UTC, and compare against the RESOLUTION_CHANGE_DATETIME constant directly. - Use the tz-aware boundary_iso string as the split point so downstream fromisoformat() calls always return tz-aware datetime objects. Impact: Ranges spanning 2025-10-01T00:00:00 UTC are now split correctly regardless of the UTC offset carried by the original interval strings, and no TypeError is raised when routing.py compares the boundary endpoints to its own tz-aware boundary calculation.		2026-04-06 14:08:27 +00:00
..
tibber_prices	fix(interval_pool): use tz-aware datetime comparison at resolution boundary	2026-04-06 14:08:27 +00:00