Geplante Zeiten (Scan/Update-Prüfung) laufen fest auf UTC statt der eigenen Zeitzone #10

New issue

Closed

opened 2026-08-16 07:45:40 +00:00 by AxonByteDev · 0 comments

AxonByteDev commented

2026-08-16 07:45:40 +00:00

Owner

Problem

Unter Einstellungen → Allgemein ("Automatischer Scan") und Einstellungen → Updates ("Automatische Prüfung") kann man eine Uhrzeit für den geplanten Lauf einstellen — die Auswahl ist aber ausdrücklich als "Uhr (UTC)" beschriftet. Man muss also selbst manuell in UTC umrechnen, um z. B. "jeden Tag um 4 Uhr morgens meiner Zeit" einzustellen. Das ist unpraktisch und fehleranfällig, besonders bei der Zeitumstellung (Sommer-/Winterzeit).

Codeanalyse

backend/scheduler.py: BackgroundScheduler(timezone="UTC") global, und _make_trigger() baut jeden CronTrigger(...) fest mit timezone="UTC" — betrifft den Scan-Job, den Update-Prüfungs-Job UND die Script-Zeitpläne gleichermaßen.
frontend/src/pages/Settings.tsx: CronPicker-Komponente beschriftet die Auswahl explizit mit "Uhr (UTC)", Stunde/Minute werden 1:1 in den Cron-String übernommen, keine Umrechnung.
frontend/src/pages/Scripts.tsx hat exakt dieselbe CronPicker-Komponente dupliziert (für Script-Zeitpläne) — dieselbe Einschränkung besteht dort ebenfalls.
Es gibt aktuell nirgends im Projekt (Backend noch Frontend) irgendeine Zeitzonen-Erkennung oder -Umrechnung — weder zoneinfo/pytz im Backend noch Intl.DateTimeFormat/getTimezoneOffset im Frontend.
apscheduler (bereits Abhängigkeit, siehe requirements.txt) unterstützt CronTrigger(..., timezone=...) nativ — keine neue Abhängigkeit nötig.

Vorschlag

Wichtig: Nicht clientseitig einmalig nach UTC umrechnen und nur den umgerechneten Cron-String speichern — das würde bei der nächsten Zeitumstellung um eine Stunde falsch laufen. Stattdessen die eingegebene Uhrzeit unverändert (in der lokalen Zeitzone) speichern und zusätzlich die Zeitzone selbst mitspeichern; APScheduler übernimmt dann die Umrechnung inkl. Sommer-/Winterzeit korrekt bei jedem Lauf automatisch.

Frontend: Zeitzone automatisch über Intl.DateTimeFormat().resolvedOptions().timeZone ermitteln (liefert z. B. "Europe/Berlin"), im CronPicker anzeigen/mitschicken statt "UTC" fest zu beschriften.
Backend: neue Settings-Felder (z. B. scan_cron_tz, update_check_cron_tz, analog für Script-Zeitpläne), Default "UTC" (Rückwärtskompatibilität für bereits gespeicherte Werte ohne Zeitzone).
backend/scheduler.py::_make_trigger() um einen tz-Parameter erweitern, timezone="UTC" durch den übergebenen Wert ersetzen (Fallback "UTC", falls nicht gesetzt).
Die "Nächster Scan"/"Nächste Prüfung"-Anzeige im Frontend sollte sich davon unabhängig automatisch richtig verhalten (läuft vermutlich schon client-seitig über toLocaleString).
Script-Zeitpläne (frontend/src/pages/Scripts.tsx) haben dieselbe Einschränkung — bietet sich an, im selben Zug mitzuziehen, da es exakt derselbe Code-Pfad/dieselbe Komponente ist.

Akzeptanzkriterien

Beim Öffnen der Einstellungen wird automatisch die eigene Zeitzone erkannt und angezeigt statt "UTC".
Ein gespeicherter Zeitplan läuft nach einer Zeitumstellung (Sommer-/Winterzeit) weiterhin zur eingestellten lokalen Uhrzeit, nicht eine Stunde verschoben.
Bereits vor diesem Fix gespeicherte Zeitpläne (ohne Zeitzonen-Feld) laufen unverändert weiter (Fallback UTC).

## Problem Unter Einstellungen → Allgemein ("Automatischer Scan") und Einstellungen → Updates ("Automatische Prüfung") kann man eine Uhrzeit für den geplanten Lauf einstellen — die Auswahl ist aber ausdrücklich als "Uhr (UTC)" beschriftet. Man muss also selbst manuell in UTC umrechnen, um z. B. "jeden Tag um 4 Uhr morgens meiner Zeit" einzustellen. Das ist unpraktisch und fehleranfällig, besonders bei der Zeitumstellung (Sommer-/Winterzeit). ## Codeanalyse - `backend/scheduler.py`: `BackgroundScheduler(timezone="UTC")` global, und `_make_trigger()` baut jeden `CronTrigger(...)` fest mit `timezone="UTC"` — betrifft den Scan-Job, den Update-Prüfungs-Job UND die Script-Zeitpläne gleichermaßen. - `frontend/src/pages/Settings.tsx`: `CronPicker`-Komponente beschriftet die Auswahl explizit mit "Uhr (UTC)", Stunde/Minute werden 1:1 in den Cron-String übernommen, keine Umrechnung. - `frontend/src/pages/Scripts.tsx` hat exakt dieselbe `CronPicker`-Komponente dupliziert (für Script-Zeitpläne) — dieselbe Einschränkung besteht dort ebenfalls. - Es gibt aktuell nirgends im Projekt (Backend noch Frontend) irgendeine Zeitzonen-Erkennung oder -Umrechnung — weder `zoneinfo`/`pytz` im Backend noch `Intl.DateTimeFormat`/`getTimezoneOffset` im Frontend. - `apscheduler` (bereits Abhängigkeit, siehe `requirements.txt`) unterstützt `CronTrigger(..., timezone=...)` nativ — keine neue Abhängigkeit nötig. ## Vorschlag **Wichtig:** Nicht clientseitig einmalig nach UTC umrechnen und nur den umgerechneten Cron-String speichern — das würde bei der nächsten Zeitumstellung um eine Stunde falsch laufen. Stattdessen die eingegebene Uhrzeit unverändert (in der lokalen Zeitzone) speichern und zusätzlich die Zeitzone selbst mitspeichern; APScheduler übernimmt dann die Umrechnung inkl. Sommer-/Winterzeit korrekt bei jedem Lauf automatisch. - Frontend: Zeitzone automatisch über `Intl.DateTimeFormat().resolvedOptions().timeZone` ermitteln (liefert z. B. `"Europe/Berlin"`), im `CronPicker` anzeigen/mitschicken statt "UTC" fest zu beschriften. - Backend: neue Settings-Felder (z. B. `scan_cron_tz`, `update_check_cron_tz`, analog für Script-Zeitpläne), Default `"UTC"` (Rückwärtskompatibilität für bereits gespeicherte Werte ohne Zeitzone). - `backend/scheduler.py::_make_trigger()` um einen `tz`-Parameter erweitern, `timezone="UTC"` durch den übergebenen Wert ersetzen (Fallback `"UTC"`, falls nicht gesetzt). - Die "Nächster Scan"/"Nächste Prüfung"-Anzeige im Frontend sollte sich davon unabhängig automatisch richtig verhalten (läuft vermutlich schon client-seitig über `toLocaleString`). - Script-Zeitpläne (`frontend/src/pages/Scripts.tsx`) haben dieselbe Einschränkung — bietet sich an, im selben Zug mitzuziehen, da es exakt derselbe Code-Pfad/dieselbe Komponente ist. ## Akzeptanzkriterien - Beim Öffnen der Einstellungen wird automatisch die eigene Zeitzone erkannt und angezeigt statt "UTC". - Ein gespeicherter Zeitplan läuft nach einer Zeitumstellung (Sommer-/Winterzeit) weiterhin zur eingestellten lokalen Uhrzeit, nicht eine Stunde verschoben. - Bereits vor diesem Fix gespeicherte Zeitpläne (ohne Zeitzonen-Feld) laufen unverändert weiter (Fallback UTC).

AxonByteDev closed this issue

2026-09-17 16:16:15 +00:00

AxonByteDev referenced this issue from a commit

2026-09-17 16:17:48 +00:00

feat: Zeitpläne laufen in der eigenen Zeitzone statt fest in UTC (#10)

AxonByteDev referenced this issue

2026-09-17 16:46:23 +00:00

Release v1.1.4 #12