docs(savepoint): Uhrzeit-Meldung erledigt - mit dem Beweis, der zaehlt

Die "Substantial drift 7200 seconds"-Meldung kam nicht alle paar Sekunden,
sondern einmal pro Absender-Hostname (celery memoized nach hostname) - und der
Container-Hostname wechselt bei jedem Neubau. Die vier Meldungen im Log sind
genau vier Deploys.

Der Beweis, dass sie weg ist: Um 14:57:33 synchronisierte sich der Worker mit
celery@d160eb2f3afd, dem frischen Container nach dem Deploy. Ein NEUER Hostname
umgeht die Merk-Sperre, die Warnung haette also feuern muessen. Sie kam nicht.
Dazu gemessen: TZ=UTC wirkt auf Windows wirklich (time.timezone -3600 -> 0), und
die celery-Zeitstempel im lokalen Worker-Log stehen in UTC.

Ausserdem festgehalten: Der Windows-Worker laeuft auf gemischten Dateistaenden
(tasks.py 13:19, ripping.py 14:06, zombies.py 14:17) - die Sprachwahl ist
vollstaendig drin, meta_merken fehlt noch. Es fehlt eine Versionsanzeige, die
so etwas sichtbar macht, statt es nur beim Nachsehen auf dem PC zu finden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

SAVEPOINT.md

@@ -126,7 +126,62 @@ RIPPY_REPO_URL=<gitea> \
 RIPPY_ENV_SRC=/home/arcane/projects/rippy/.env ./deploy.sh
 ```
 
-### 4. Was noch offen ist
+### 4. Die Uhrzeit-Meldung: nachgemessen statt gehofft
+
+Zwei offene Fragen zur `Substantial drift … 7200 seconds`-Meldung, beide jetzt
+beantwortet.
+
+**Wirkt `set TZ=UTC` auf Windows überhaupt?** Das war ungeprüft — und die
+MSVC-Dokumentation verlangt eigentlich die Form `UTC0`. Hier gemessen:
+
+| | `time.timezone` | `time.altzone` | `isdst` |
+|---|---|---|---|
+| ohne `TZ` | −3600 | −7200 | 1 |
+| `TZ=UTC` | **0** | −3600 | **0** |
+| `TZ=UTC0` | 0 | −3600 | 0 |
+
+Celerys `utcoffset()` rechnet `time.timezone // 3600` (bzw. `altzone`, wenn
+`isdst`) — mit `TZ=UTC` also 0, genau wie in den Containern. `TZ=UTC` genügt,
+`UTC0` bringt nichts zusätzlich.
+
+**Warum kam die Meldung „immer wieder"?** Sie kam nicht alle paar Sekunden,
+sondern **einmal pro Absender**:
+
+```python
+@memoize(maxsize=1000, keyfun=lambda a, _: a[0])
+def _warn_drift(hostname, drift, local_received, timestamp):
+    # we use memoize here so the warning is only logged once per hostname
+```
+
+Der Absender ist der Linux-Container, und dessen Hostname wechselt bei **jedem
+Neubau**. Die Meldungen im Log (`7e71250606aa`, `09d001df95a4`, `7c2c179a1953`,
+`3a9f4808ed51`) sind genau vier Deploys — deshalb kam sie „immer wieder", ohne
+zwischendurch zu nerven.
+
+**ERLEDIGT, und zwar sauber bewiesen.** Aus dem lokalen Worker-Log auf dem
+PC (`%LOCALAPPDATA%\Rippy Worker\worker.log`):
+
+```
+[2026-07-26 14:21:17,301: INFO/MainProcess] tobisnicerpc@TobisNicerPC ready.
+[2026-07-26 14:23:17,318: WARNING/MainProcess] Zombie-Erkennung: {...}
+[2026-07-26 14:57:33,460: INFO/MainProcess] sync with celery@d160eb2f3afd
+```
+
+Zwei Dinge stehen da:
+
+1. Die Zeitstempel sind **UTC** (14:21, während es auf dem PC 16:21 war) —
+   `TZ=UTC` ist im laufenden Worker also wirklich aktiv.
+2. Um 14:57:33 kam ein **neuer** Absender-Hostname dazu (der Container von
+   heute Abend). Genau dafür ist die Merk-Sperre blind — die Warnung hätte
+   feuern MÜSSEN. Sie kam nicht.
+
+Nebenbei ist damit auch die Log-Brücke bestätigt: Die Zeilen von 14:21 und
+14:23 stehen als `w:tobisnicerpc` in Rippys Log. (Ich hatte sie zuerst
+übersehen, weil `/logs` neueste-zuerst liefert und ich `tail` statt `head`
+gefiltert hatte — die Liste war nicht leer, ich habe an der falschen Seite
+geschaut.)
+
+### 5. Was noch offen ist
 
 - **Voller Durchlauf läuft gerade** (Job `bfb7a946`, über den neuen
   `retry-rip`-Weg gestartet): Akira-BD → Auswurf → Kompression auf
@@ -141,6 +196,21 @@ RIPPY_ENV_SRC=/home/arcane/projects/rippy/.env ./deploy.sh
 - **`sudo ./install.sh` auf einem FRISCHEN Host ist weiter unbelegt.** Der
   Prüfpfad (`--nur-pruefen`) läuft auf der VM sauber durch, alle fünf Prüfungen
   grün. Ein echter Root-Lauf hier hätte den laufenden Rip getötet.
+- **Der Windows-Worker läuft auf gemischten Dateiständen** — direkt auf dem PC
+  nachgesehen (`C:\Program Files\Rippy Worker`): `tasks.py` 13:19, `ripping.py`
+  14:06, `zombies.py` 14:17. Die Sprachwahl ist vollständig drin (geprüft:
+  `tasks.py` liest sie, `ripping.py` gibt sie an HandBrake), `meta_merken`/
+  `RIP_FERTIG` von heute Abend fehlen noch. Für diesen Test unerheblich (die
+  Marke setzt der Linux-Worker bei der Übergabe), aber **nach dem Test einmal
+  den Installer laufen lassen**, damit alles auf einem Stand ist.
+- **Es fehlt eine Versionsanzeige für den externen Worker.** Nichts vergleicht
+  seinen Code-Stand mit dem des Servers; „läuft auf gemischten Ständen" war nur
+  zu sehen, weil ich auf dem PC selbst nachgesehen habe. Ein Zähler in `caps.py`
+  (z. B. der Commit-Kurz-Hash) und eine Warnung im UI wären der saubere Weg —
+  bewusst nicht heute Nacht gebaut.
+- **Im Wurzelverzeichnis der Freigabe liegt eine verwaiste
+  `Evangelion 2.22_t00.mkv`** ohne zugehörigen Job. Kann weg, wenn du sie nicht
+  brauchst — Rippy zeigt sie nirgends an, weil kein Eintrag darauf zeigt.
 
 ---