+1 Std. Zeitversatz

Ich hoffe du hast meine ganzen Nachdenk Nachträge noch lesen können. Siehe
https://www.blog.dokumenzi.ch/2635-kuerzlich-aufgefallen.html#c6941

Export/Import ist nicht die Lösung. denn der Kasus Knacktus ist der differente Offset. Beim Import bleibt dasjenige erhalten was der Export als dump hervorbrachte. Man könnte höchstens den Datenbank Export dump so einstellen, dass alle gewünschten timestamps (und zwar nur die) um 3600 Sekunden - also 1 Stunde ins Minus gerechnet werden. Eher schwierig... aber ein Datenbank Houdini wäre dazu sicher flugs in der Lage - auch treffsicher genau nur für jene Einträge, die in diesem Mitternachtszeitraum liegen.

Doch es gibt immer wieder Beiträge, bei denen das nicht der Fall ist.

Das müsste man aber herauszufinden suchen, ob das wirklich so ist und wenn, dann Warum.

Ich persönlich würde jetzt nur die Nahtstellen bearbeiten. Da du ja sowieso mit der history arbeitest, hast du ja dann in der Folge jeweils eine kleinen Happen zum nacharbeiten und zwar immer nur da, wo Inhalt und Zeitstempel nicht mehr wirklich passen. Alles andere ist vernachlässigbar.

Kopie von Kommentar: https://www.blog.dokumenzi.ch/2579-Styx-Stand-01.05.2020,-1058.html#c6952

OK mache dir vorher mal ein Backup der entries Tabelle, sicherheitshalber.

Alles in einem Rutsch!

Dann:

UPDATE styx_entries AS T1,
      (SELECT id, timestamp, DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H:%m' ) AS time
        FROM styx_entries 
        WHERE timestamp <= 1572732840 AND DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H' ) = '23') AS T2 
  SET T1.timestamp=(T2.timestamp - 3600)
WHERE T1.id = T2.id;

661 Datensätze betroffen.
Überprüfe mit

SELECT id, timestamp, DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H:%m' ) AS time from styx_entries WHERE timestamp <= 1572732840 AND DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H' ) = '23' ORDER BY time ASC

müsste jetzt leer sein.

Stoppp!

Lies besonders die letzten 2 Kommentare.

Warum um 2 Stunden (und wo)?

ACHTUNG: In der Datenbank - als timestamp sind sie 1 Stunde zurück, weil der damalige Offset +1 war. Da er jetzt +2 ist, muss der timestamp nur noch eine weitere Stunde zurückgerechnet werden. Was du im Backend entryform als Eintragsdatum angezeigt bekommst, ist bereits das um das Offset korrigierte Datum aus den Datenbank timestamps, in dem Fall +2 Stunden.

Du hast nicht verstanden! ? Mehr Kaffee. Los! ☺

2005-12-22T00:54 ist bereits aus dem Datenbank timestamp berechnet + 2 Stunden also 7200. Du willst ja, so wie es auf dem Originalblog war, auf die Uhrzeit 2005-12-21T23:54 kommen, also musst du den Datenbank timestamp nur noch um eine weitere Stunde zurücksetzen. Entryform Anzeige und Datenbank Anzeige differieren um den zur letzten Speicherung (die auch das Datum+Zeit betraf) gesetzten Offset.

Das einzige was du im Kopf behalten solltest, ist, dass dies ein workaround ist, um die neuralgischen Einträge, die hinüberrutschen, zu korrigieren. Als eine Folge könnte jetzt entstehen, dass ehemalige 22 Uhr Einträge (die ja heute 23:xx wären) mit deinen neuen 23 Uhr Einträgen ähem "kollidieren" - entweder in der zeitlichen Abfolge oder im inhaltlichen Bezug. Um alles in den alten Zustand bei neuem Offset zu versetzen, müssten halt wirklich alle (alten) Einträge korrigiert werden. Aber da hattest du ja gesagt, es gäbe welche, bei denen der Versatz nicht zuträfe (was eigentlich nicht sein kann, außer du warst es selbst).