Ich war gedanklich am falschen Ort. Du meintest die Änderung der functions_entries.inc.php und ich bezog mich auf die nachher durchgeführten SQL-Abfragen.
Auch in diesem Fall arbeitete ich mit mehreren geöffneten Fenstern. Ich lud die abgeänderte Datei hoch, refreshte das Archiv, kopierte die angezeigte Meldung, fügte den Inhalt in einem anderen Fenster in den gemeinsamen Beitrag, wechselte das Fenster zu diesem Blog und schrieb den Kommentar. Alles hat weniger als 3 Minuten gedauert. Ganz sicher nicht 5 Minuten.
Fortführung von https://www.blog.dokumenzi.ch/index.php?url=2635-kuerzlich-aufgefallen.html#c6870
So. Ich habe mich gerade mal kurz um das 2 Stunden Problem gekümmert. Ich glaube es ist u.U. ein sehr alter Bug. Mit Serendipity 1.1 (2006) wurde der genannte SQL cache eingeführt, der ja dieses 5 Minuten Zeitfenster erlaubt. Das hohe Alter dieses "Bugs" stimmt mich gerade deshalb etwas unsicher, da es nahezu unwahrscheinlich scheint, dass bisher keiner darüber gestolpert ist. Etwas an das dabei wohl nie gedacht wurde, ist die ServerOffset Zeitverschiebung, so wie bei dir.
Allerdings handelt es sich hier ja um die Startzeit der Abfrage und nicht um falsche Berechnungen zum nächtlichen Übergang alter Einträge. Also eigentlich etwas, was nur bestimmte counter ab dem augenblicklichen timestamp und die eventuelle Einbeziehung von zukünftigen Einträgen bestimmen sollte. Insofern würde ich das gerne mal sehen bevor ich das allgemein commite. Vielleicht handelt es sich hier um das fixen eines Problems was uns mit dem November Problem (und bitte so lassen) gar nicht explizit betrifft.
Bitte ändere (auf beatsblog) mal in der include/functions.inc.php in Zeile 1448 das
$now = time();
in
$now = serendipity_serverOffsetHour();
Ach nee, wir können mit der Änderung vorerst hier auf dokumenzi bleiben. Das ist ja gleich.
Beat Post author am |
Habe die geänderte functions.inc.php nun hochgeladen.
Ehrlich gesagt verwundert mich das jedoch nicht, dass dies noch keinem vorher aufgefallen ist. Die Fehlzählung tritt ja nur dann auf, wenn ein Beitrag entweder am letzten Monatstag zwischen 22:00 und 23:59 oder am ersten Monatstag zwischen 00:00 und 01:59 Uhr veröffentlicht wurde. Und ich schrieb hier extra entweder oder, denn vermutlich trifft es ja nur in einem dieser beiden Fälle zu. Und zusätzlich: Wer hinterfragt schon die angezeigte Anzahl Beiträge im Archiv? Plus/Minus 1 fällt doch niemandem auf. Wären bei mir die Abweichungen wegen dem entrypaging-Plugin nicht grösser gewesen, hätte ich das auch nie bemerkt.
Nun ja, wie ich schon schrieb, wird serendipity_db_time() zB auch verwendet, wenn es um die Freischaltung bzw Anzeige/Einbeziehung von zukünftigen Einträgen geht. Und da hätte es in all den Jahren doch sicher mal jemanden mit wachem Blick geben müssen...
Allerdings, wie schon vermutet, hat dieser Fix keine Folgewirkung für unser Problem. Ich habe heute Morgen dann noch ein wenig weiter geforscht und mir kam dabei zähneknischend der Verdacht, dass es sich vielleicht um ein weit größeres und folgenreicheres Problem handeln könnte als bisher gedacht.
Dazu musste ich dich nochmal - erinnerungsweise - bemühen.
Bei mir (also meinem lokalen beatblog mit deinen entries) ist in entry ID 2063, also "lang ist's her", der Datumstempel unangetastet auf 2013-11-30T23:59, so wie der dump daher kam. Im Archiv wird November 13 mit 7 angezeigt und die Ausgabe iderselben st auch 7, inklusive diesem Eintrag. Also ohne Fehler. Ich habe allerdings auch keinen Offset, also + 2 Stunden. Auf dokumenzi ist dieser Eintrag mit 2013-12-01T00:59 getimed und auch auch auf beatsblog, wie du selbst ausgeführt hast.
Jetzt zur Frage. Wann und warum hast du diesem Eintrag eine neue Zeit gegeben? Und hast du jemals hinterher nochmal nachgesehen, ob er tatsächlich genau den Datumsstempel auffweist, den du zur Änderung angegeben hattest? Diese Frage ließe sich erweitern auf alle Einträge, die du in den letzten Monaten mal neu aufgesetzt hast und die in der genannten Zeit bis 2 Stunden nach Mitternacht spielen.
Wenn sich das eventuell bestätigt, was ich vermute, haben wir das Problem das theoretisch viele Beiträge in einem älteren Blog falsch eingestellt sind, weil möglichwerweise das Ändern des Zeitstempel nicht die serverOffsetHour() mit berechnet hat. Und das wäre dann mehr als nur eine Stelle.
Beat Post author am |
Oft schreibe ich Beiträge einen Tag später und datiere sie dann zurück. Früher wählte ich jeweils das richtige Datum und 23:59 Uhr als Uhrzeit. Ich dachte damals, dass es (für mich) wichtig sei zu erkennen, ob es sich um einen rückdatierten Beitrag handelt oder nicht. Das machte ich mindestens so lange, wie in der Frontenddarstellung nicht nur das Beitragsdatum, sondern auch die Uhrzeit dargestellt wurde. Irgendwann ist man von dieser Darstellung abgekommen und zeigt nur noch das Beitragsdatum. (Seither ändere ich zum Rückdatieren nur noch das Datum).
Ich habe meine GPS-Track-Datensammlung durchsucht und die beschriebene Tour fand tatsächlich am Samstag 30.11.2013 und nicht am Sonntag 01.12.2013 statt. Somit behaupte ich jetzt ganz einfach mal: Ich schrieb den Beitrag am Sonntag, habe ihn dann jedoch (vor dem erstmaligen speichern) auf den Samstag, 30.11.2013, 23:59 Uhr, zurückdatiert.
Ich kann mir jetzt nur vorstellen, dass beim Import der Entry-Daten in die neue DB ein Server-Zeitversatz von +1 Std. angewendet wurde und der Beitrag nun auf 01.12.2013, 00:59 Uhr eingetragen wurde. Eine andere Erklärung habe ich nicht. Das würde aber auch bedeuten, dass diverse (um nicht zu sagen unzählige) Beiträge nun am Folgetag dargestellt werden. Nur: Ich habe ja keine Möglichkeit um eine Selektion "zeige mir alle Beiträge, die zwischen 00:55 und 01:05 Uhr gespeichert wurden" durchzuführen um so diese Beiträge zu finden.
Mit etwas zeitlicher Distanz, verliert das aber auch an Wichtigkeit. Aus heutiger Sicht ist es doch völlig egal, ob der Beitrag "lang ist's her" am 30.11.2013 oder am 01.12.2013 publiziert wurde.
Übrigens: Im alten Originalblog war/ist der Beitrag noch immer auf den 30.11.2013 datiert und somit stimmt auch die Anzahl Beiträge im Archiv. Siehe: https://bbbeat.ch/archives/2013/11/summary.html
Auch deshalb denke ich, dass ich mir "dieses Problem" beim Datenimport generiert habe.
Beat Post author am |
Habe noch ein paar 23:59 Uhr Beispiele überprüft und kann sagen: Ja, alle erscheinen nun einen Tag später, mit Uhrzeit 00:59 Uhr.
Auch wenn ich andere, importierte Beiträge ansehe: Alle importierten Beiträge sind nun + 1 Std. später datiert. Das bedeutet: Alle Originalbeiträge, welche einen Zeitstempel zwischen 23:00 und 23:59 hatten, sind nun in den Folgetag gerutscht.
...in die neue DB ein Server-Zeitversatz von +1 Std. angewendet wurde...
Das wäre auch eine interessante Erklärung, und war da nicht gerade erst was mit 1 Stunde und hostech (?, siehe c6858 ?), würde allerdings bedeuten, dass alle Einträge um 1 Stunde verschoben wurden, auch wenn man es problematisch nur bei der Mitternachtgeschichte befinden könnte.
Ich hatte jedenfalls auch noch in Verdacht, dass bei bestimmten nachträglichen Eintragsänderungen mit neuerem Zeitstempel time() statt serverOffsetHour() verwendet wird. Es gibt solche Stellen, auch wenn ich noch nicht genau nachsehen und verstehen konnte, ob sie dort absichtlich oder nur vergessenerweise als time() initiisiert werden.
Beat Post author am |
Es ist schon so: Zum Zeitpunkt des Ex- und Imports aller Daten war die Zeit bei hostech Serverzeit + 1 Std. (Export) und bei manitu Serverzeit + 2 Std. (Import).
Weshalb nun, seit der Umstellung auf Sommerzeit, die Konfiguration für beide Hoster bei Serverzeit + 2 Std. liegt, ist mir völlig unklar.
Ja das kann dann wohl passieren, wenn der alte Server und der neue Server sich im OffsetHour unterscheiden. Woran man so alles denken muss...!
Was ich nicht verstehe ist, sollte es nur ein Server offsetHour Verschiebungsproblem sein, warum das Zählen dann fehlschlägt❓❔❓ Denn wenn sich alle um eine Stunde verschieben, ist das eben so und bildet die dann (neue) Grundlage für das Abzählen, oder ⁉
Beat Post author am |
Du spricht damit an, dass das Archiv im November 2013 trotzdem 7 Einträge zählt, obwohl der letzte in den Dezember gerutscht ist und somit nur deren 6 dargestellt werden? Da kann ich Dir leider so gar nicht weiterhelfen.
Interessant ist ja auch, dass selbst wenn ich den Eintrag auf 01:59 Uhr datiere, wird er noch gezählt. Für das Archiv fällt er erst ab 02:01 Uhr in den Dezember. Das +1 Std. Import-Problem scheint mit dem Archiv-Zählproblem (+2 Std.) nichts zu tun zu haben.
Immerhin verwenden wir Logik um die einzelnen Schritte, die schlußendlich zur beobachteten Fehlkalkulation führen, voneinander abzugrenzen und die hoffentlich richtigen Schlüsse zu ziehen!
Von drei haben wir also 2 schon genau eruiert! [Hoffentlich!]
Beat Post author am |
Ich habe jetzt einen Testeintrag mit Zeitstempel 01.11.2013, 01:00 Uhr, erstellt. In der Übersicht zählt das November-Archiv nun immer noch 7 Beiträge und wenn man die einzelnen Beiträge sich auflisten lässt, so sind es jetzt deren 7.
Dafür zählt der Oktober nun 13 Beiträge, obwohl nur deren 12 dargestellt werden. Das heisst: der neue Testeintrag wird mitgezählt (falsch) aber nicht dargestellt (korrekt).
Ich schliesse daraus: Der Fehler von +2 Std. entsteht nur bei der Zählung der Beiträge, weil von ersten Tag des Monats 02:00 Uhr bis zum ersten Tag des Folgemonats 02:00 Uhr gezählt wird. Die Darstellung der Beiträge danach, erfolgt aber völlig korrekt.
Und genau an der Stelle beißt sich der Hund in den Schwanz!
Das Archiv speist sich aus einer einzigen Funktion, serendipity_printArchives(). Diese sagt, hole alle entry timestamps ab augenblicklichen timestamp. Die hooks haben wir bereits korrigiert. Das augenblickliche timestamp haben wir bereits korrigiert. Und nur zähle zusammen nach Jahr/Monat.... doch stooopppppppp!Gleich habe ich es ... nur noch ... wenn ich auf das summary vom Monat gehe, also /archives/2013/11/summary.html, und ich sehe du hast herumgefummelt, kommt der fetch der angezeigten Einträge ja von woanders her und zwar richtig.
Die Frage ist also, wie kann er sich in der printarchive Summierung um 2 Stunden verzählen? Muss die serverOffsetHour auf negate gesetzt werden, damit 2 Stunden abgezählt werden? Macht das irgendwie Sinn? Wenn es jetzt etwas wirr klingt ist dies dem guten Rose zuzuschreiben. Hicks! ?
Aber wir sind wohl beide auf der richtigen Spur sehe ich gerade.... ?
Beat Post author am |
Das alles ist sehr, sehr dubios. Die Aussage, dass es alle importierten Beiträge betrifft stimmt nicht. Beispiel:
/1269-Hoernli.html ist auf bbeat und beatsblog datiert auf 09.05.2009, 23:59 Uhr
/1655-aufs-Hoernli.html ist auf bbbeat datiert auf 15.01.2011, 23:59 Uhr und auf beatsblog auf 16.01.2001, 00:59 Uhr
Es ist auch kein bestimmter Zeitpunkt auszumachen, ab welchem der Zeitversatz auftritt. Wenn im oben genannten Beispiel 2009 noch o.k. ist, so finde ich im Jahr 2008 wieder ein Beispiel, wo der Versatz drin ist.
/941-Tour-aufs-Hoernli.html ist auf bbbeat datiert auf 09.02.2008, 22:07 Uhr und auf beatsblog auf 23:07 Uhr
Es scheint also ziemlich zufällig und somit kann ich den Gedanken, alle Beiträge um eine Stunde zurückzuversetzen, wohl auch abschreiben. Es sieht so aus, dass ich ganz einfach mit dieser unbekannten Anzahl von "verschobenen" Beiträgen leben muss.
Nee, ich glaube das passt schon (irgendwie), denn du hattest bei den Hörnli Geschichten herumgefummelt, als es um die Zählweise des search Requests ging. Erinnerst du dich?
Nur um das dazu anzumerken (für hellere Stunden ?) bei mir ist Hörnli im Einzelbeitrag als Sonntag, Mai 10. 2009 ausgeschildert. Aber im History (Gott seis gedankt gerade anwesend) als Sa, 09.05.2009 23:59 Hörnli. Schwant dir da was?
Ich hatte jedenfalls auch noch in Verdacht, dass bei bestimmten nachträglichen Eintragsänderungen mit neuerem Zeitstempel time() statt serverOffsetHour() verwendet wird. Es gibt solche Stellen, auch wenn ich noch nicht genau nachsehen und verstehen konnte, ob sie dort absichtlich oder nur vergessenerweise als time() initiisiert werden.
Also ich werde mich jetzt gleich der Besinnung zuwenden, sonst zaubere ich da noch irgendwelche Terroirs hinein... in vino veritas ?, glaube aber inzwischen, dass ich damit falsch liege. Es geht ja gerade darum, dass der create timestamp GMT ist und erst in der diversen Folge mit serverOffsetHour() abgeglichen wird.
Beat Post author am |
Das ist auf www.beatsblog.ch NICHT so! Dieser Beitrag (https://www.beatsblog.ch/1269-Hoernli.html) wird bei mir mit Datum "Samstag, 9. Mai 2009" angezeigt. Das ist identisch mit dem Ursprungsblog (https://bbbeat.ch/1269-Hoernli.html). Aber: Vergiss dieses Thema!
Dein Thema ist eher, weshalb das Archiv falsch zählt (die + 2 Std. Geschichte).
Beat Post author am |
Ich war gedanklich am falschen Ort. Du meintest die Änderung der functions_entries.inc.php und ich bezog mich auf die nachher durchgeführten SQL-Abfragen.
Auch in diesem Fall arbeitete ich mit mehreren geöffneten Fenstern. Ich lud die abgeänderte Datei hoch, refreshte das Archiv, kopierte die angezeigte Meldung, fügte den Inhalt in einem anderen Fenster in den gemeinsamen Beitrag, wechselte das Fenster zu diesem Blog und schrieb den Kommentar. Alles hat weniger als 3 Minuten gedauert. Ganz sicher nicht 5 Minuten.
Ian Styx am |
Alles gut.
Hast du übrigens dem freetag auch schon das update verpasst, anlog zu ct ?
Beat Post author am |
Das Update des Freetag-Plugins wurde mir erst heute angeboten. Habe jetzt beide Systeme aktualisiert.
Ian Styx am |
Fortführung von https://www.blog.dokumenzi.ch/index.php?url=2635-kuerzlich-aufgefallen.html#c6870
So. Ich habe mich gerade mal kurz um das 2 Stunden Problem gekümmert. Ich glaube es ist u.U. ein sehr alter Bug. Mit Serendipity 1.1 (2006) wurde der genannte SQL cache eingeführt, der ja dieses 5 Minuten Zeitfenster erlaubt. Das hohe Alter dieses "Bugs" stimmt mich gerade deshalb etwas unsicher, da es nahezu unwahrscheinlich scheint, dass bisher keiner darüber gestolpert ist. Etwas an das dabei wohl nie gedacht wurde, ist die ServerOffset Zeitverschiebung, so wie bei dir.
Allerdings handelt es sich hier ja um die Startzeit der Abfrage und nicht um falsche Berechnungen zum nächtlichen Übergang alter Einträge. Also eigentlich etwas, was nur bestimmte counter ab dem augenblicklichen timestamp und die eventuelle Einbeziehung von zukünftigen Einträgen bestimmen sollte. Insofern würde ich das gerne mal sehen bevor ich das allgemein commite. Vielleicht handelt es sich hier um das fixen eines Problems was uns mit dem November Problem (und bitte so lassen) gar nicht explizit betrifft.
Bitte ändere (auf
beatsblog) mal in der include/functions.inc.php in Zeile 1448 das$now = time();
in
$now = serendipity_serverOffsetHour();
Ian Styx am |
Ach nee, wir können mit der Änderung vorerst hier auf dokumenzi bleiben. Das ist ja gleich.
Beat Post author am |
Habe die geänderte functions.inc.php nun hochgeladen.
Ehrlich gesagt verwundert mich das jedoch nicht, dass dies noch keinem vorher aufgefallen ist. Die Fehlzählung tritt ja nur dann auf, wenn ein Beitrag entweder am letzten Monatstag zwischen 22:00 und 23:59 oder am ersten Monatstag zwischen 00:00 und 01:59 Uhr veröffentlicht wurde. Und ich schrieb hier extra entweder oder, denn vermutlich trifft es ja nur in einem dieser beiden Fälle zu. Und zusätzlich: Wer hinterfragt schon die angezeigte Anzahl Beiträge im Archiv? Plus/Minus 1 fällt doch niemandem auf. Wären bei mir die Abweichungen wegen dem entrypaging-Plugin nicht grösser gewesen, hätte ich das auch nie bemerkt.
Ian Styx am |
Nun ja, wie ich schon schrieb, wird serendipity_db_time() zB auch verwendet, wenn es um die Freischaltung bzw Anzeige/Einbeziehung von zukünftigen Einträgen geht. Und da hätte es in all den Jahren doch sicher mal jemanden mit wachem Blick geben müssen...
Allerdings, wie schon vermutet, hat dieser Fix keine Folgewirkung für unser Problem. Ich habe heute Morgen dann noch ein wenig weiter geforscht und mir kam dabei zähneknischend der Verdacht, dass es sich vielleicht um ein weit größeres und folgenreicheres Problem handeln könnte als bisher gedacht.
Dazu musste ich dich nochmal - erinnerungsweise - bemühen.
Bei mir (also meinem lokalen beatblog mit deinen entries) ist in entry ID 2063, also "lang ist's her", der Datumstempel unangetastet auf 2013-11-30T23:59, so wie der dump daher kam. Im Archiv wird November 13 mit 7 angezeigt und die Ausgabe iderselben st auch 7, inklusive diesem Eintrag. Also ohne Fehler. Ich habe allerdings auch keinen Offset, also + 2 Stunden. Auf dokumenzi ist dieser Eintrag mit 2013-12-01T00:59 getimed und auch auch auf beatsblog, wie du selbst ausgeführt hast.
Jetzt zur Frage. Wann und warum hast du diesem Eintrag eine neue Zeit gegeben? Und hast du jemals hinterher nochmal nachgesehen, ob er tatsächlich genau den Datumsstempel auffweist, den du zur Änderung angegeben hattest? Diese Frage ließe sich erweitern auf alle Einträge, die du in den letzten Monaten mal neu aufgesetzt hast und die in der genannten Zeit bis 2 Stunden nach Mitternacht spielen.
Wenn sich das eventuell bestätigt, was ich vermute, haben wir das Problem das theoretisch viele Beiträge in einem älteren Blog falsch eingestellt sind, weil möglichwerweise das Ändern des Zeitstempel nicht die serverOffsetHour() mit berechnet hat. Und das wäre dann mehr als nur eine Stelle.
Beat Post author am |
Oft schreibe ich Beiträge einen Tag später und datiere sie dann zurück. Früher wählte ich jeweils das richtige Datum und 23:59 Uhr als Uhrzeit. Ich dachte damals, dass es (für mich) wichtig sei zu erkennen, ob es sich um einen rückdatierten Beitrag handelt oder nicht. Das machte ich mindestens so lange, wie in der Frontenddarstellung nicht nur das Beitragsdatum, sondern auch die Uhrzeit dargestellt wurde. Irgendwann ist man von dieser Darstellung abgekommen und zeigt nur noch das Beitragsdatum. (Seither ändere ich zum Rückdatieren nur noch das Datum).
Ich habe meine GPS-Track-Datensammlung durchsucht und die beschriebene Tour fand tatsächlich am Samstag 30.11.2013 und nicht am Sonntag 01.12.2013 statt. Somit behaupte ich jetzt ganz einfach mal: Ich schrieb den Beitrag am Sonntag, habe ihn dann jedoch (vor dem erstmaligen speichern) auf den Samstag, 30.11.2013, 23:59 Uhr, zurückdatiert.
Ich kann mir jetzt nur vorstellen, dass beim Import der Entry-Daten in die neue DB ein Server-Zeitversatz von +1 Std. angewendet wurde und der Beitrag nun auf 01.12.2013, 00:59 Uhr eingetragen wurde. Eine andere Erklärung habe ich nicht. Das würde aber auch bedeuten, dass diverse (um nicht zu sagen unzählige) Beiträge nun am Folgetag dargestellt werden. Nur: Ich habe ja keine Möglichkeit um eine Selektion "zeige mir alle Beiträge, die zwischen 00:55 und 01:05 Uhr gespeichert wurden" durchzuführen um so diese Beiträge zu finden.
Mit etwas zeitlicher Distanz, verliert das aber auch an Wichtigkeit. Aus heutiger Sicht ist es doch völlig egal, ob der Beitrag "lang ist's her" am 30.11.2013 oder am 01.12.2013 publiziert wurde.
Übrigens: Im alten Originalblog war/ist der Beitrag noch immer auf den 30.11.2013 datiert und somit stimmt auch die Anzahl Beiträge im Archiv. Siehe: https://bbbeat.ch/archives/2013/11/summary.html
Auch deshalb denke ich, dass ich mir "dieses Problem" beim Datenimport generiert habe.
Beat Post author am |
Habe noch ein paar 23:59 Uhr Beispiele überprüft und kann sagen: Ja, alle erscheinen nun einen Tag später, mit Uhrzeit 00:59 Uhr.
Auch wenn ich andere, importierte Beiträge ansehe: Alle importierten Beiträge sind nun + 1 Std. später datiert. Das bedeutet: Alle Originalbeiträge, welche einen Zeitstempel zwischen 23:00 und 23:59 hatten, sind nun in den Folgetag gerutscht.
Ian Styx am |
Das wäre auch eine interessante Erklärung, und war da nicht gerade erst was mit 1 Stunde und hostech (?, siehe c6858 ?), würde allerdings bedeuten, dass alle Einträge um 1 Stunde verschoben wurden, auch wenn man es problematisch nur bei der Mitternachtgeschichte befinden könnte.
Ich hatte jedenfalls auch noch in Verdacht, dass bei bestimmten nachträglichen Eintragsänderungen mit neuerem Zeitstempel time() statt serverOffsetHour() verwendet wird. Es gibt solche Stellen, auch wenn ich noch nicht genau nachsehen und verstehen konnte, ob sie dort absichtlich oder nur vergessenerweise als time() initiisiert werden.
Beat Post author am |
Es ist schon so: Zum Zeitpunkt des Ex- und Imports aller Daten war die Zeit bei hostech Serverzeit + 1 Std. (Export) und bei manitu Serverzeit + 2 Std. (Import).
Weshalb nun, seit der Umstellung auf Sommerzeit, die Konfiguration für beide Hoster bei Serverzeit + 2 Std. liegt, ist mir völlig unklar.
Ian Styx am |
Ah, siehe da ?
Ja das kann dann wohl passieren, wenn der alte Server und der neue Server sich im OffsetHour unterscheiden. Woran man so alles denken muss...!
Was ich nicht verstehe ist, sollte es nur ein Server offsetHour Verschiebungsproblem sein, warum das Zählen dann fehlschlägt❓❔❓ Denn wenn sich alle um eine Stunde verschieben, ist das eben so und bildet die dann (neue) Grundlage für das Abzählen, oder ⁉
Beat Post author am |
Du spricht damit an, dass das Archiv im November 2013 trotzdem 7 Einträge zählt, obwohl der letzte in den Dezember gerutscht ist und somit nur deren 6 dargestellt werden? Da kann ich Dir leider so gar nicht weiterhelfen.
Interessant ist ja auch, dass selbst wenn ich den Eintrag auf 01:59 Uhr datiere, wird er noch gezählt. Für das Archiv fällt er erst ab 02:01 Uhr in den Dezember. Das +1 Std. Import-Problem scheint mit dem Archiv-Zählproblem (+2 Std.) nichts zu tun zu haben.
Ian Styx am |
Ja genau!
Immerhin verwenden wir Logik um die einzelnen Schritte, die schlußendlich zur beobachteten Fehlkalkulation führen, voneinander abzugrenzen und die hoffentlich richtigen Schlüsse zu ziehen!
Von drei haben wir also 2 schon genau eruiert! [Hoffentlich!]
Beat Post author am |
Ich habe jetzt einen Testeintrag mit Zeitstempel 01.11.2013, 01:00 Uhr, erstellt. In der Übersicht zählt das November-Archiv nun immer noch 7 Beiträge und wenn man die einzelnen Beiträge sich auflisten lässt, so sind es jetzt deren 7.
Dafür zählt der Oktober nun 13 Beiträge, obwohl nur deren 12 dargestellt werden. Das heisst: der neue Testeintrag wird mitgezählt (falsch) aber nicht dargestellt (korrekt).
Ich schliesse daraus: Der Fehler von +2 Std. entsteht nur bei der Zählung der Beiträge, weil von ersten Tag des Monats 02:00 Uhr bis zum ersten Tag des Folgemonats 02:00 Uhr gezählt wird. Die Darstellung der Beiträge danach, erfolgt aber völlig korrekt.
Ian Styx am |
Und genau an der Stelle beißt sich der Hund in den Schwanz!
Das Archiv speist sich aus einer einzigen Funktion, serendipity_printArchives(). Diese sagt, hole alle entry timestamps ab augenblicklichen timestamp. Die hooks haben wir bereits korrigiert. Das augenblickliche timestamp haben wir bereits korrigiert. Und nur zähle zusammen nach Jahr/Monat.... doch stooopppppppp! Gleich habe ich es ... nur noch ... wenn ich auf das summary vom Monat gehe, also /archives/2013/11/summary.html, und ich sehe du hast herumgefummelt, kommt der fetch der angezeigten Einträge ja von woanders her und zwar richtig.
Die Frage ist also, wie kann er sich in der printarchive Summierung um 2 Stunden verzählen? Muss die serverOffsetHour auf negate gesetzt werden, damit 2 Stunden abgezählt werden? Macht das irgendwie Sinn?
Wenn es jetzt etwas wirr klingt ist dies dem guten Rose zuzuschreiben. Hicks! ?
Aber wir sind wohl beide auf der richtigen Spur sehe ich gerade.... ?
Beat Post author am |
Das alles ist sehr, sehr dubios. Die Aussage, dass es alle importierten Beiträge betrifft stimmt nicht. Beispiel:
Es ist auch kein bestimmter Zeitpunkt auszumachen, ab welchem der Zeitversatz auftritt. Wenn im oben genannten Beispiel 2009 noch o.k. ist, so finde ich im Jahr 2008 wieder ein Beispiel, wo der Versatz drin ist.
Es scheint also ziemlich zufällig und somit kann ich den Gedanken, alle Beiträge um eine Stunde zurückzuversetzen, wohl auch abschreiben. Es sieht so aus, dass ich ganz einfach mit dieser unbekannten Anzahl von "verschobenen" Beiträgen leben muss.
Ian Styx am |
Nee, ich glaube das passt schon (irgendwie), denn du hattest bei den Hörnli Geschichten herumgefummelt, als es um die Zählweise des search Requests ging. Erinnerst du dich?
Ian Styx am |
Würde ich vorerst auch nicht machen, denn das macht keinen wirklichen Sinn.
Beat Post author am |
Ja, ja, damals ging es um die Such-Ergebnisse. Da habe ich nichts an den Beiträgen geändert. Das hat damit nichts zu tum.
Ian Styx am |
Nur um das dazu anzumerken (für hellere Stunden ?) bei mir ist Hörnli im Einzelbeitrag als Sonntag, Mai 10. 2009 ausgeschildert. Aber im History (Gott seis gedankt gerade anwesend) als Sa, 09.05.2009 23:59 Hörnli. Schwant dir da was?
Ian Styx am |
Also ich werde mich jetzt gleich der Besinnung zuwenden, sonst zaubere ich da noch irgendwelche Terroirs hinein... in vino veritas ?, glaube aber inzwischen, dass ich damit falsch liege. Es geht ja gerade darum, dass der create timestamp GMT ist und erst in der diversen Folge mit serverOffsetHour() abgeglichen wird.
Beat Post author am |
Das ist auf www.beatsblog.ch NICHT so! Dieser Beitrag (https://www.beatsblog.ch/1269-Hoernli.html) wird bei mir mit Datum "Samstag, 9. Mai 2009" angezeigt. Das ist identisch mit dem Ursprungsblog (https://bbbeat.ch/1269-Hoernli.html). Aber: Vergiss dieses Thema!
Dein Thema ist eher, weshalb das Archiv falsch zählt (die + 2 Std. Geschichte).
Wünsche einen schönen Abend!
Ian Styx am |
Stimmt! Ich hatte den testblog auf +2 gesetzt.
Ebenso!