Time Fix #2

New Issue

groot · 2026-04-27T18:04:24Z

groot commented

2026-04-27 18:04:24 +00:00

Bitte einmal direkt prüfen

Führe in MySQL aus:

SELECT
@@global.time_zone AS global_tz,
@@session.time_zone AS session_tz,
NOW(6) AS now_session,
UTC_TIMESTAMP(6) AS now_utc;

Wenn NOW(6) und UTC_TIMESTAMP(6) um 2 Stunden auseinanderliegen, erklärt das dein Problem.

Dann prüfe die Spalten:

SHOW COLUMNS FROM event_logs LIKE 'ts';
SHOW COLUMNS FROM event_logs LIKE 'received_at';
SHOW COLUMNS FROM detections LIKE 'created_at';
SHOW COLUMNS FROM host_risk_scores LIKE 'last_detection_at';
SHOW COLUMNS FROM host_risk_scores LIKE 'updated_at';

Und für konkrete Daten:

SELECT
id,
ts,
received_at,
TIMESTAMPDIFF(MINUTE, ts, received_at) AS diff_minutes
FROM event_logs
ORDER BY id DESC
LIMIT 20;

Wenn dort häufig 120 steht, ist received_at lokal gespeichert.

Für Detections:

SELECT
id,
created_at,
UTC_TIMESTAMP(6) AS utc_now,
TIMESTAMPDIFF(MINUTE, created_at, UTC_TIMESTAMP(6)) AS age_minutes
FROM detections
ORDER BY id DESC
LIMIT 20;

Wenn neue Detections scheinbar „in der Zukunft“ liegen oder 2 Stunden daneben sind, kommt created_at nicht sauber als UTC.

Wichtig: Alte Daten bleiben falsch

Die Codeänderung behebt neue Inserts. Bereits falsch gespeicherte Werte bleiben falsch.

Wenn du sicher bist, dass z. B. detections.created_at aktuell CEST-Wandzeit enthält, obwohl du UTC erwartest, kannst du alte Daten korrigieren:

UPDATE detections
SET created_at = DATE_SUB(created_at, INTERVAL 2 HOUR)
WHERE created_at > UTC_TIMESTAMP(6);

Das ist aber nur sicher, wenn du genau weißt, dass diese Werte wirklich +2 falsch sind. Wegen Sommer-/Winterzeit würde ich für historische Daten vorsichtig sein.

Für Tests reicht meist: Code ändern, Anwendung neu starten, neue Detection erzeugen, prüfen.

Bitte einmal direkt prüfen Führe in MySQL aus: SELECT @@global.time_zone AS global_tz, @@session.time_zone AS session_tz, NOW(6) AS now_session, UTC_TIMESTAMP(6) AS now_utc; Wenn NOW(6) und UTC_TIMESTAMP(6) um 2 Stunden auseinanderliegen, erklärt das dein Problem. Dann prüfe die Spalten: SHOW COLUMNS FROM event_logs LIKE 'ts'; SHOW COLUMNS FROM event_logs LIKE 'received_at'; SHOW COLUMNS FROM detections LIKE 'created_at'; SHOW COLUMNS FROM host_risk_scores LIKE 'last_detection_at'; SHOW COLUMNS FROM host_risk_scores LIKE 'updated_at'; Und für konkrete Daten: SELECT id, ts, received_at, TIMESTAMPDIFF(MINUTE, ts, received_at) AS diff_minutes FROM event_logs ORDER BY id DESC LIMIT 20; Wenn dort häufig 120 steht, ist received_at lokal gespeichert. Für Detections: SELECT id, created_at, UTC_TIMESTAMP(6) AS utc_now, TIMESTAMPDIFF(MINUTE, created_at, UTC_TIMESTAMP(6)) AS age_minutes FROM detections ORDER BY id DESC LIMIT 20; Wenn neue Detections scheinbar „in der Zukunft“ liegen oder 2 Stunden daneben sind, kommt created_at nicht sauber als UTC. Wichtig: Alte Daten bleiben falsch Die Codeänderung behebt neue Inserts. Bereits falsch gespeicherte Werte bleiben falsch. Wenn du sicher bist, dass z. B. detections.created_at aktuell CEST-Wandzeit enthält, obwohl du UTC erwartest, kannst du alte Daten korrigieren: UPDATE detections SET created_at = DATE_SUB(created_at, INTERVAL 2 HOUR) WHERE created_at > UTC_TIMESTAMP(6); Das ist aber nur sicher, wenn du genau weißt, dass diese Werte wirklich +2 falsch sind. Wegen Sommer-/Winterzeit würde ich für historische Daten vorsichtig sein. Für Tests reicht meist: Code ändern, Anwendung neu starten, neue Detection erzeugen, prüfen.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sendnrw/siem-backend#2