fix: accept colon-less +0100 last_updated in is_running() on Python 3.9/3.10

[headbouyJB]

Problem

record_status() writes the status entity's last_updated attribute with TIME_FORMAT (%Y-%m-%dT%H:%M:%S%z, const.py), and strftime('%z') never emits a colon in the UTC offset. datetime.fromisoformat() only accepts the colon-less form from Python 3.11, so on 3.9/3.10 is_running() fails to parse Predbat's own timestamp and returns False — the web dashboard shows a false "(unhealthy)" status and the API ping endpoint 500s. Installs on 3.11+ never see it, which is why this was not caught internally.

Change

Following the first of the two options in the automated triage on #5181 (keep the naive tolerance at the reader, rather than changing the writer): changing record_status() to emit .isoformat() would alter the format of an attribute other consumers read — web.py already parses this same attribute with str2time() — while the reader-side change leaves what is stored untouched and simply accepts what has always been written.

In is_running(): parse with utils.str2time() first (its strptime fallback handles +0100 on all Python versions); on ValueError, fall back to datetime.fromisoformat() so a legacy naive last_updated — still persisted on installs upgraded from before record_status() wrote a timezone-aware value — reaches the existing naive-now comparison branch instead of being rejected as unparseable (preserving the tolerance added in b8cb0350). The outer except (ValueError, TypeError) still returns False.

load_plan() is left unchanged: its plan_last_updated is written via .isoformat() (always the colon form), so that call site is not affected by this bug — and swapping it to str2time() would have regressed its naive-timestamp fallback to UTC.

Tests

Extended the existing is_running() coverage in apps/predbat/tests/test_web_functions.py: a fresh last_updated must report running in all three formats the attribute can hold — +0100 (the writer's format), +01:00, and the legacy naive form. Each case also spies on predbat.str2time and requires the value to be handed to it, so reverting the fix fails the test on every Python version, not only 3.9/3.10.

$ python3 unit_test.py -t web_functions
...
Test: is_running() handles both naive and timezone-aware last_updated
**** Web functions tests completed ****
**** Test web_functions PASSED in 0.00s (end 19:05:37) ****
**** All tests passed (total time: 0.00s) ****

CI runs Python 3.11+, where fromisoformat() accepts +0100, so the format cases alone would pass there without the fix; the str2time() spy is what makes the test fail on CI if the fix is reverted. The underlying bug was reproduced on Python 3.9.6 against the repo's real helpers:

>>> s = datetime.now().astimezone().strftime("%Y-%m-%dT%H:%M:%S%z")   # '2026-10-10T19:06:00+0100'
>>> datetime.fromisoformat(s)
ValueError: Invalid isoformat string: '2026-10-10T19:06:00+0100'      # the bug
>>> str2time(s)                                                        # parses
>>> str2time(str(datetime.now()))  -> ValueError
>>> datetime.fromisoformat(str(datetime.now()))                        # fallback parses, naive-now branch reached

pre-commit (ruff, black, cspell) passes on the changed files.

Closes #5181

AI assistance

Drafted with AI assistance (Warden, an OpenClaw agent running local Qwen models); reviewed and submitted by me.

[Copilot]

🟡 Changes recommended

The regression test does not distinguish the fixed implementation on the Python version used by CI.

1 open finding

• Compatibility tests do not catch regression on latest Python · New

What changed in this PR

Fixes Python 3.9/3.10 health checks by parsing status timestamps with the cross-version helper while preserving legacy naive timestamps.

Changes:

• Uses str2time() with a naive-timestamp fallback.
• Adds coverage for supported timestamp formats.

File	Description
apps/​predbat/​predbat.py	Makes status timestamp parsing cross-version compatible.
apps/​predbat/​tests/​test_web_functions.py	Adds timestamp-format regression cases.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.