Datenbank: workernote auf 10.0.0.3:50002
Umgebung:  PRODUCTION

PHP
---
date.timezone (php.ini) : UTC
Anwendungszeitzone      : Europe/Berlin (+02:00)
date('Y-m-d H:i:s')     : 2026-10-03 18:32:13
gmdate('Y-m-d H:i:s')   : 2026-10-03 16:32:13

MySQL – so, wie der Server die Verbindung von sich aus aufsetzt
-----------------------------------------------------------------
global.time_zone        : Europe/Berlin
session.time_zone       : Europe/Berlin
system_time_zone        : CEST
NOW()                   : 2026-10-03 18:32:13
UTC_TIMESTAMP()         : 2026-10-03 16:32:13
CURDATE()               : 2026-10-03
Offset zu UTC           : +2.00 Stunden
Zeitzonentabellen       : 1793 Einträge (Zeitzonennamen nutzbar)

Abgleich
--------
OK – PHP und MySQL laufen auf demselben Offset.
     Vergleiche zwischen PHP-Datumswerten und NOW() sind hier gültig.

Warum die Session-Zeitzone nicht erzwungen wird
-----------------------------------------------
TIMESTAMP-Spalten werden intern in UTC abgelegt und beim Lesen in die
Session-Zeitzone umgerechnet. DATE, TIME und DATETIME sind nicht betroffen.
Zum Vergleich wird hier probeweise auf den festen Offset +02:00 umgestellt.
Zeilen mit 'VERSCHIEBT SICH' stammen aus einer anderen Jahreszeit: 'SYSTEM'
kennt die Sommerzeitumstellung, ein fester Offset nicht.

Spalte                       mit SYSTEM            mit festem Offset     Bewertung
projektchat.createdAtUtc     2026-07-13 10:53:58   2026-07-13 10:53:58   unverändert
bibliothek.createdAtUtc      2025-04-26 15:11:52   2025-04-26 15:11:52   unverändert
timetracking.updatedAt       2026-10-02 15:53:30   2026-10-02 15:53:30   unverändert
terminaluser.starttime       2026-10-02 13:22:10   2026-10-02 13:22:10   unverändert

Fertig. Es wurden keine Daten verändert.