Hatte das noch um eine (erste) Zeile erweitert. Bei mir (lokal ohne Offset) steht das letzte Datum deines ersten entries auf 2005-12-16 23:55:00 also eine Stunde weiter. Korreliert das mit unseren bisherigen Beobachtungen?
... ich weiss nicht ...
Der erste Beitrag:
www.bbbeat.ch = 16.12.2005 23:55 (= Original = richtig)
www.blog.dokumenzi.ch = 17.12.2005 00:55
www.beatsblog.ch = 17.12.2005 00:55
Wir müssen aufpassen, dass wir vom selben sprechen. Bis anhin dachte ich, dieses Problem ( 1 Std. Zeitverschiebung der Beiträge nach hinten) sei daher gekommen, weil der Manitu-Server ein anderes Offset hatte als der hosttech-Server. Also, dass ich mir das Problem beim Import eingehandelt habe. Die Auflistung zeigt aber, dass ich dieses Problem bereits im Dezember, beim Import in diesen Blog hatte. Und dieser Blog (blog.dokumenzi) läuft auf dem gleichen Server wie der Original-Blog (bbbeat). Also denke ich im Moment, dass ich das Problem nicht beim Import, sondern beim Export erzeugt habe. (Wieso auch immer).
In meinen Augen ist das Archiv-Zähl-Problem davon unabhängig. Das Archiv zählt zwar falsch (vom 01. um 02:00 bis am 01. des Folgemonats um 02:00), listet aber beim Klick auf den Monat -oder die gezählten Beiträge- alle Beiträge korrekt auf. Nämlich die, die zwischen dem 01. 00:00 Uhr und dem 30/31. 24:00 Uhr datiert sind.
Ich glaube noch immer, dass dies zwei verschiedene Probleme sind. Das Erste ist m.M.n. kein Styx- sondern ein Beat-Problem. Nur das Zweite ist ein Serendipity-Styx-Problem.
Also: Sehe ich das falsch? Und falls ich das richtig sehe, dann ist es für die Tests doch unerheblich, ob die TimeStamp der Beiträge richtig oder falsch sind. Wenn sie in den Zeitraum eines Monats fallen, sollen sie gezählt werden und sonst nicht. Basta.
Beat Post author am |
Kann es sein, dass bbbeat.ch auf einem anderen Server läuft als dokumenzi.ch (obwohl ich bei hosttech nur ein Hostingpaket habe)? So sieht es in der Serendipity-Konfiguration aus: Es ist aktuell 18:05 Uhr.
bbbeat.ch = Zeitunterschied des Servers = 0 (Gibt an, wie viele Stunden zwischen der Uhrzeit des Servers (aktuell: 18:05) und der eigenen Zeitzone liegen.)
blog.dokumenzi.ch = Zeitunterschied des Servers = 2 (Gibt an, wie viele Stunden zwischen der Uhrzeit des Servers (aktuell: 16:05) und der eigenen Zeitzone liegen.)
Ob es im Original richtig ist, nehmen wir nur an. Das ist nicht völlig sicher. Aber es ist der Ausgangspunkt unserer Betrachtungen. Und du hast völlig recht, egal wie sie sind, die timestamps, sie sind diejenigen auf denen alles beruht. Kommt es also zu Fehldarstellungen, ist es ein Problem der korrekten Umrechnung, auch wenn der eine Server im Offset weiter als der Vorherige sein sollte, da ja "früher" beim Schreiben eines entries, der timestamp auf Grundlage des dortigen Offsets zurück errechnet wurde, in dem Fall -1, nicht wahr ⁉ Ich meine im Übrigen auch, dass das mit Sy9 genauso sein müsste, da ich diesbezüglich nicht wirklich etwas bewußt geändert habe, ... aber wer weiß es genau...! Die Frage ist ja zB., ob man mit den jetzigen 2 Stunden Einstellung den Zähl-Fehler noch einmal produzieren kann bei einem neuen Eintrag oder einem nachbearbeiten kann, der auf diesem Server zuerst angelegt wurde. Könnstest du das mal testen?
Auf alle Fälle sagt uns die Archiv Debug Ausgabe, das der erste Eintrag 2005-12-16 22:55:00 von PHPs default strftime() Funktion um 1 Std in die Vergangenheit Zukunft errechnet wird. Ich bessere sogleich nochmal nach, um auch eine strftime mit Offset Ausgabe zu erhalten. Ebenso sagt uns die Debug Ausgabe, dass die Änderung in der serendipity_db_time einerseits eine gute und vielleicht sogar richtige Idee war, denn sie zeigt ja auf den richtigen aktuellen lokalen Zeitstempel mit Offset als Start - wobei der Start timestamp sich aber wohl doch nach der DB Serverzeit richten sollte, also muss man die serendipity_db_time wieder zurück auf time() setzen.
Das Debugging hat mir also noch keine Lampe gebracht die alles in Wohlgefallen auflösen könnte.
Ja natürlich kann das wohl sein. Je nach Platzfrage zum Zeitpunkt der Erstellung. Und die waren bestimmt unterschiedlich, oder? Sicher muss die Unternehmensphilosophie das hergeben, aber die Möglichkeit besteht sicher, und die beiden unterschiedlichen Offsets deuten darauf hin. Zur Not kann man ja auch mal nachfragen, zur sicheren Klärung.
Allerings haben wir jetzt noch eine Variable mehr zu Klärung. Und ich bin schon verwirrt genug! ?
Es würde aber erklären, warum bbbeat.ch und meine lokale entries Kopie übereinstimmen.
OK Danke der Teilnahme. Kannst alle debugs wieder entfernen? Am besten die Datei https://raw.githubusercontent.com/ophian/styx/master/include/functions_entries.inc.php mit "Speichern unter" abspeichern und per FTP einfach hochladen. Sie enthält schon ein paar weitere Verbesserungen beim Zähler (löst aber noch nicht das eigentliche Problem). Hast du den serendipity_db_time "fix"-Versuch in der functions.inc schon wieder zuruckgesetzt?
Ich habe heute Morgen (mit frischem Kopf) ein wenig herumgespielt.
Eine Test timestamp Änderung eines hiesig (+2) zuerst erstellten Blog Eintrags (ja es ist dieser) von 2020-03-21T19:53auf2020-03-31T23:53 erbrachte keine Auswirkung im Archiv-Listen-Zähler. Aber mit 2020-03-01T00:53 ist der Zähler um 1 verrutscht. Es verzählt sich dann im Jahr 2020
also 5 4 2 13 (echt 5 4 2 13) zu 5 3 3 13 (echt 5 4 2 13) (April März Februar Januar).
Außerdem bemerkbar, vertut sich der Zähler ganz unabhängig vom timeframe cache.
Ergo schließe ich daraus, dass nur Monatsanfänge wie 2020-03-01T00:53 mit Zeitstempel
zwischen 00:00 und 00:59 bzw 01:59 diesen Fehler aufweisen und dann für den (und nur den)
nächsten Monat weitergeben. Noch nicht klar habe ich, ob analog ein "1999-08-01T01:53"
erstellter Eintrag (also zurzeiten des +1 Offsets) dasselbe macht. Haben wir eine Beispiel,
das so bereits besteht, also auf 1. Tag des Monats und die Zeit zwischen 01:00 und 01:59 steht?
Bitte vorläufig nicht weiter herumändern an älteren Beiträgen, die ein solches Muster aufweisen.
Wenn alles gut geht und wir diesen Zählfehler in der weiteren Folge wegbekommen, dann erst kann man daran gehen, diese alten Eintrags-Muster an das neue Offset anzupassen, also dass sie nicht mehr weiterrutschen, so das Problem dann noch besteht. Denn klar ist ja, die Offsets sind durch den Serverwechsel anders. Also verrückt sich die Stunde so oder so. Nur macht es ja bei den aller-allermeisten Einträge überhaupt gar nichts aus, wenn sie um 1 Stunde verrückt werden, außer, es entspricht dem Muster oder ist so explizit (!) von dir gewünscht.
Nachdem du das gemacht hast und wir uns beide mal die Archiv Liste daraufhin haben ansehen
und überprüfen können, lies bitte mal unseren Eintrag mit einer weiteren erst dann folgenden Anweisung nach.
Spricht irgendetwas meinem Schluss entgegen?
Beat Post author am |
Am besten die Datei https://raw.githubusercontent.com/ophian/styx/master/include/functions_entries.inc.php mit "Speichern unter" abspeichern und per FTP einfach hochladen.
Gemacht.
Hast du den serendipity_db_time "fix"-Versuch in der functions.inc schon wieder zuruckgesetzt?
Pfff... ich weiss nicht genau, Habe soeben die Originaldatei vom letzten Download (01.05.20) hochgeladen und die bestehende Datei damit überschrieben.
Beat Post author am |
? you made my day! ?
Habe ich nicht genau dies bereits am Sonntag, im Kommentar #6898, beschrieben? Zitat:
Es gibt einen Blogeintrag mit Timestamp 01.06.2011, zwischen 00:00 und 01:59 Uhr. Dieser fehlt im Monat 5 (deshalb werden 17 angezeigt und 18 gezählt). Dieser wird im Monat 6 angezeigt, aber nicht gezählt. Dies, weil jeweils vom 01. des Monats ab 02:00 Uhr bis zum 01. des Folgemonats, ebenfalls um 02:00 Uhr, gezählt wird.
...
Nachtrag: Es handelt sich um folgenden Beitrag: /2276-Italien-Radreise-2011.html (TimeStamp: 01.06.2011 00:01). Dieser wird im Mai mitgezählt aber nicht dargestellt und im Juni ist es umgekehrt.
Wie gesagt: Es geht hier nur um das Zählen der Beiträge im Archiv. Völlig losgelöst von der Offset-Diskussion der Entry-Timestamp.
Beat Post author am |
Haben wir eine Beispiel, das so bereits besteht, also auf 1. Tag des Monats und die Zeit zwischen 01:00 und 01:59 steht?
Ja schon - aber nicht unter Auschluss der übrigen! ?
Und du darfst nicht vergessen dass ich das auch noch verstehen musste! ?
Ich habe übrigens entry 2642 gerade mal als draft verstaut, damit man das ordentlich auch für das Jahr 13 mitbekommt. Da geht es ja nicht um November ➡ Oktober, sondern um Dezember ➡ November..
Ok habe es gesehen. Wie erwartet keine wesentliche Änderung. Jetzt warte ich noch auf einen eventuellen Eintrag aus deiner jetzigen Suche.
Erst dann gehts weiter mit dem Text.
Beat Post author am |
Es gibt keinen Eintrag, welcher an einem 1. Monatstag, zwischen 01:00 und 01:59 Uhr gespeichert wurde. Hätte mich auch verwundert. Denn das hiesse ja, dass ich trotz 1 Std. Zeitversatz, diesen Artikel nach Mitternacht geschrieben habe. Das ist eher unwahrscheinlich und wenn doch, hätte ich ihn bestimmt zurückdatiert. ?
Das habe ich gefunden:
01.02.2008, 00:11, #932, nicht so einfach
01.01.2010, 00:59, 1413, Silvester 2009
01.02.2011, 00:59, 1666, Januar-Abschluss
01.03.2011, 00:08, 1681, Monatsabschluss
01.06.2011, 00:01, 2276, Italien-Radreise 2011
01.12.2011, 00:59, 1848, ich weiss schon...
01.11.2013, 01:00, 2642, Testeintrag (09.05.2020)
01.12.2013, 00:59, 2063, lang ist's her
JA, sehr gut! Danke!
Das scheint das zu bestätigen, auch wenn kein Eintrag zwischen 1°° und 2°° dabei ist. Denn immer wenn einer so ist und als startender Monat daherkommt, verzählt es sich in Folge bis zum letzen Monat mit Muster, nicht jeweils +1 verschoben im nächsten, denn wir haben ja 2011 mehrere Monate hintereinander die das genau zeigen.
Bitte jetzt ausführen! Jetzt bin ich sehr gespannt!
Beat Post author am |
o.k. functions_entries.inc.php angepasst und hochgeladen.
Mir ist übel..! ? Den einzigen Schluss den ich daraus ziehen kann ist, alles ist gut! Kein Grund für irgendwelche Änderungen im code. Es wird auch nicht falsch gezählt. Das einzige was gelitten hat, ist unsere Zeit und der Hirnschmalz der dafür draufgegangen ist.
Setze sie - und das ist eben das Gute. denn jetzt hast du ja bereits eine Liste die du schnell abarbeiten kannst - zurück nach dem jetzt gültigen Offset und alles sollte gut sein. Das ist eben nicht automagisch zu erledigen, sondern eine Folge des Offsetwechsels.
Oder ⁉
Beat Post author am |
❓
Also bei mir sieht es noch genau gleich (falsch) aus, wie zuvor. Muss ich den Browser-Cache leeren um eine Verbesserung zu sehen?
Ich kam zum Schluss das kein Fehler vorliegt. Der jetzige Code ist so geschrieben, dass er nur ordentlich mit einem einmal gesetzten Offset arbeitet. Er hat keine Absicht Offsetwechsel selbst erzählerisch zu reparieren. Diese Nahtstellen bei einem Wechsel des Offsets müssen daher (immer) von Hand korrigiert werden. Fertig.
Ich könnte mir auch gut vorstellen, dass ein Teil der History Problematik ebenso damit zusammenhängt.
Beat Post author am |
Ich verstehe es nicht.
Erkläre mir doch bitte, wieso im November 2013 Archiv 7 Beiträge gezählt aber nur deren 6 aufgelistet werden.
Dezember: 17 Einträge mit echten 17
November: 7 Einträge mit echten 7
Verwirrend ist wahrscheinlich die Rückwärt/Vorwärtsportierung was wohl daran liegt dass der Zähler rückwärts arbeitet
for ($m = 12; $m >= 1; $m--)
und die timestamps minus des offsets geformt werden.
Nachtrag: Wenn ich bei mir offset 2 eingebe, sieht das genauso aus wie bei dir.
Nachtrag 2: Genau dieser Richtungswechsel aufwärts / abwärts je nach Zähler und Ausgabe sind das total Verwirrende. Besser ist es sich an das Datum zu halten. Du hast den Artikel am 30. November um 23:11 geschrieben. Also eindeutig ein November Artikel. In die Datenbank wurde er durch das damalige Offset +1 also um -1 zurück als timestamp konvertiert und eingetragen, also 22:11. Jetzt aber wird aus 22:11 mit +2 offset schon der nächste Monat. Alles klar ⁉ ?
Nachtrag 3: Jetzt zur Frage, warum er eigentlich falsch zählt. Der Zähler fragt in dem loop JahrMonat aus dem timestamp ab und zählt die gleichen als Counter hoch. Das ist das was als Zahl ausgegeben wird. Die entries dieses Monats werden aber durch eine echte Abfrage an anderer Stelle gebildet und nicht durch die falsche ZählerZahl in der Folge bestimmt.
Nachtrag 4: Das artet ja zum comic aus und erinnert mich stark an "Es greent so green - she's got it. she's got it!". Wir haben also immer falsch herum gedacht, jedenfalls ich! Der Zähler ist nicht falsch, sondern richtig. Aber die Einträge sind falsch und zwar durch den Offsetwechsel. So herum macht es erst Sinn. Und alles kann man durch das Datum herleiten, so wie in Nachtrag 2 erklärt.
Ich denke schreibend, also werde ich! Jetzt besser? ?
Beat Post author am |
Vielen Dank für die grosse Mühe, welche Du Dir für die Erlärung(en) gemacht hast. Ich gebe zu, dass ich es nicht vollständig verstanden habe, doch das ist auch nicht so wichtig.
Meine Sicht ist aktuell wie folgt: www.beatsblog.ch hat ein Problem mit allen Beiträgen, die eine Eintragszeit zwischen 00:00 und 02:00 ausgeben. Diesen kann ich nicht trauen. In >95% der Fälle sind diese falsch, denn sie wurden ursprünglich am Vortag geschrieben und gehörten demzufolge eben zurückdatiert. Es gibt dann aber noch die <5% der Fälle, die richtig sind in dem Sinne, dass sie entweder tatsächlich kurz nach Mitternacht geschrieben wurden oder wie z.B. der Beitrag /2276-Italien-Radreise-2011.html (TimeStamp: 01.06.2011 00:01), welcher ganz bewusst auf diesen Zeitpunkt gespeichert wurde.
Ich bin leider kein SQL-DB-Crack und kenne auch keinen. Hilfreich wäre eine Auflistung aller Beiträge, die eben einen Zeitstempel zwischen 00:00 und 02:00 Uhr tragen. So könnte ich diese gezielt öffnen, Datum und Zeit ändern und wieder abspeichern. Das werden hunderte von Beiträgen sein... Da der timestamp jedoch eine absolute Zahl ist, die (vermutlich) irgendwie von einem Nullpunkt her errechnet wird, sehe ich keine Chance via DB-Abfrage zu einer solchen Liste zu kommen.
In einem ersten Schritt habe ich nun mal die monatsübergreifenden Beiträge aus dem Kommentar #6933 zurückdatiert und somit stimmt zumindest das Monatsarchiv wieder.
Für die Zukunft denke ich, dass ich an verregneten Tagen X Stunden investieren werde und alle > 2'500 Beiträge via "Einträge bearbeiten" überprüfen und gegebenenfalls korrigieren werde. Tja... eine bessere Idee habe ich nicht.
Solltet ihr je in Versuchung kommen uns zu folgen und nun mehr nicht schlafen können, da ihr die Auflösung verpasst habt, hier (und in den Kommentaren) geht es weiter: https://www.blog.dokumenzi.ch/2643-+1-Std.-Zeitversatz.html
Beat Post author am |
Heute wieder ein leeres history-daylist.dat auf www.beatsblog.ch. TimeStamp: 02:00:28. Gemäss Logfile war dieser Zugriff der Auslöser:
Beat Post author am |
nimmt Bezug auf: https://www.blog.dokumenzi.ch/2635-kuerzlich-aufgefallen.html#c6918
... ich weiss nicht ...
Der erste Beitrag:
Wir müssen aufpassen, dass wir vom selben sprechen. Bis anhin dachte ich, dieses Problem ( 1 Std. Zeitverschiebung der Beiträge nach hinten) sei daher gekommen, weil der Manitu-Server ein anderes Offset hatte als der hosttech-Server. Also, dass ich mir das Problem beim Import eingehandelt habe. Die Auflistung zeigt aber, dass ich dieses Problem bereits im Dezember, beim Import in diesen Blog hatte. Und dieser Blog (blog.dokumenzi) läuft auf dem gleichen Server wie der Original-Blog (bbbeat). Also denke ich im Moment, dass ich das Problem nicht beim Import, sondern beim Export erzeugt habe. (Wieso auch immer).
In meinen Augen ist das Archiv-Zähl-Problem davon unabhängig. Das Archiv zählt zwar falsch (vom 01. um 02:00 bis am 01. des Folgemonats um 02:00), listet aber beim Klick auf den Monat -oder die gezählten Beiträge- alle Beiträge korrekt auf. Nämlich die, die zwischen dem 01. 00:00 Uhr und dem 30/31. 24:00 Uhr datiert sind.
Ich glaube noch immer, dass dies zwei verschiedene Probleme sind. Das Erste ist m.M.n. kein Styx- sondern ein Beat-Problem. Nur das Zweite ist ein Serendipity-Styx-Problem.
Also: Sehe ich das falsch? Und falls ich das richtig sehe, dann ist es für die Tests doch unerheblich, ob die TimeStamp der Beiträge richtig oder falsch sind. Wenn sie in den Zeitraum eines Monats fallen, sollen sie gezählt werden und sonst nicht. Basta.
Beat Post author am |
bbbeat.ch = Zeitunterschied des Servers = 0 (Gibt an, wie viele Stunden zwischen der Uhrzeit des Servers (aktuell: 18:05) und der eigenen Zeitzone liegen.)
blog.dokumenzi.ch = Zeitunterschied des Servers = 2 (Gibt an, wie viele Stunden zwischen der Uhrzeit des Servers (aktuell: 16:05) und der eigenen Zeitzone liegen.)
Jetzt bin ich total verwirrt.
Ian Styx am |
Ob es im Original richtig ist, nehmen wir nur an. Das ist nicht völlig sicher. Aber es ist der Ausgangspunkt unserer Betrachtungen. Und du hast völlig recht, egal wie sie sind, die timestamps, sie sind diejenigen auf denen alles beruht. Kommt es also zu Fehldarstellungen, ist es ein Problem der korrekten Umrechnung, auch wenn der eine Server im Offset weiter als der Vorherige sein sollte, da ja "früher" beim Schreiben eines entries, der timestamp auf Grundlage des dortigen Offsets zurück errechnet wurde, in dem Fall -1, nicht wahr ⁉ Ich meine im Übrigen auch, dass das mit Sy9 genauso sein müsste, da ich diesbezüglich nicht wirklich etwas bewußt geändert habe, ... aber wer weiß es genau...! Die Frage ist ja zB., ob man mit den jetzigen 2 Stunden Einstellung den Zähl-Fehler noch einmal produzieren kann bei einem neuen Eintrag oder einem nachbearbeiten kann, der auf diesem Server zuerst angelegt wurde. Könnstest du das mal testen?
Auf alle Fälle sagt uns die Archiv Debug Ausgabe, das der erste Eintrag 2005-12-16 22:55:00 von PHPs default strftime() Funktion um 1 Std in die
VergangenheitZukunft errechnet wird. Ich bessere sogleich nochmal nach, um auch eine strftime mit Offset Ausgabe zu erhalten. Ebenso sagt uns die Debug Ausgabe, dass die Änderung in der serendipity_db_time einerseits eine gute und vielleicht sogar richtige Idee war, denn sie zeigt ja auf den richtigen aktuellen lokalen Zeitstempel mit Offset als Start - wobei der Start timestamp sich aber wohl doch nach der DB Serverzeit richten sollte, also muss man die serendipity_db_time wieder zurück auf time() setzen.Das Debugging hat mir also noch keine Lampe gebracht die alles in Wohlgefallen auflösen könnte.
Ian Styx am |
Ja natürlich kann das wohl sein. Je nach Platzfrage zum Zeitpunkt der Erstellung. Und die waren bestimmt unterschiedlich, oder? Sicher muss die Unternehmensphilosophie das hergeben, aber die Möglichkeit besteht sicher, und die beiden unterschiedlichen Offsets deuten darauf hin. Zur Not kann man ja auch mal nachfragen, zur sicheren Klärung.
Allerings haben wir jetzt noch eine Variable mehr zu Klärung. Und ich bin schon verwirrt genug! ?
Es würde aber erklären, warum bbbeat.ch und meine lokale entries Kopie übereinstimmen.
Ian Styx am |
. Meine entries sagt "nicht alle", denn 222, 235, 268, 289, 451, 456 haben noch extended.
Beat Post author am |
? Ja, so mag das sein... Irgendwann krieg ich sie alle! Danke für die Auflistung.
Ian Styx am |
OK Danke der Teilnahme. Kannst alle debugs wieder entfernen? Am besten die Datei https://raw.githubusercontent.com/ophian/styx/master/include/functions_entries.inc.php mit "Speichern unter" abspeichern und per FTP einfach hochladen. Sie enthält schon ein paar weitere Verbesserungen beim Zähler (löst aber noch nicht das eigentliche Problem). Hast du den serendipity_db_time "fix"-Versuch in der functions.inc schon wieder zuruckgesetzt?
Ian Styx am |
Ich habe heute Morgen (mit frischem Kopf) ein wenig herumgespielt.
Eine Test timestamp Änderung eines hiesig (+2) zuerst erstellten Blog Eintrags (ja es ist dieser) von
2020-03-21T19:53 auf 2020-03-31T23:53 erbrachte keine Auswirkung im Archiv-Listen-Zähler.
Aber mit 2020-03-01T00:53 ist der Zähler um 1 verrutscht. Es verzählt sich dann im Jahr 2020
also 5 4 2 13 (echt 5 4 2 13) zu 5 3 3 13 (echt 5 4 2 13) (April März Februar Januar).
Außerdem bemerkbar, vertut sich der Zähler ganz unabhängig vom timeframe cache.
Ergo schließe ich daraus, dass nur Monatsanfänge wie 2020-03-01T00:53 mit Zeitstempel
zwischen 00:00 und 00:59 bzw 01:59 diesen Fehler aufweisen und dann für den (und nur den)
nächsten Monat weitergeben. Noch nicht klar habe ich, ob analog ein "1999-08-01T01:53"
erstellter Eintrag (also zurzeiten des +1 Offsets) dasselbe macht. Haben wir eine Beispiel,
das so bereits besteht, also auf 1. Tag des Monats und die Zeit zwischen 01:00 und 01:59 steht?
Bitte vorläufig nicht weiter herumändern an älteren Beiträgen, die ein solches Muster aufweisen.
Wenn alles gut geht und wir diesen Zählfehler in der weiteren Folge wegbekommen, dann erst kann man daran gehen, diese alten Eintrags-Muster an das neue Offset anzupassen, also dass sie nicht mehr weiterrutschen, so das Problem dann noch besteht. Denn klar ist ja, die Offsets sind durch den Serverwechsel anders. Also verrückt sich die Stunde so oder so. Nur macht es ja bei den aller-allermeisten Einträge überhaupt gar nichts aus, wenn sie um 1 Stunde verrückt werden, außer, es entspricht dem Muster oder ist so explizit (!) von dir gewünscht.
Nachdem du das gemacht hast und wir uns beide mal die Archiv Liste daraufhin haben ansehen
und überprüfen können, lies bitte mal unseren Eintrag mit einer weiteren erst dann folgenden Anweisung nach.
Spricht irgendetwas meinem Schluss entgegen?
Beat Post author am |
Gemacht.
Pfff... ich weiss nicht genau, Habe soeben die Originaldatei vom letzten Download (01.05.20) hochgeladen und die bestehende Datei damit überschrieben.
Beat Post author am |
? you made my day! ?
Habe ich nicht genau dies bereits am Sonntag, im Kommentar #6898, beschrieben? Zitat:
Wie gesagt: Es geht hier nur um das Zählen der Beiträge im Archiv. Völlig losgelöst von der Offset-Diskussion der Entry-Timestamp.
Beat Post author am |
Ich suche mal.
Ian Styx am |
Ja schon - aber nicht unter Auschluss der übrigen! ?
Und du darfst nicht vergessen dass ich das auch noch verstehen musste! ?
Ich habe übrigens entry 2642 gerade mal als draft verstaut, damit man das ordentlich auch für das Jahr 13 mitbekommt. Da geht es ja nicht um November ➡ Oktober, sondern um Dezember ➡ November..
Ian Styx am |
Ok habe es gesehen. Wie erwartet keine wesentliche Änderung. Jetzt warte ich noch auf einen eventuellen Eintrag aus deiner jetzigen Suche.
Erst dann gehts weiter mit dem Text.
Beat Post author am |
Es gibt keinen Eintrag, welcher an einem 1. Monatstag, zwischen 01:00 und 01:59 Uhr gespeichert wurde. Hätte mich auch verwundert. Denn das hiesse ja, dass ich trotz 1 Std. Zeitversatz, diesen Artikel nach Mitternacht geschrieben habe. Das ist eher unwahrscheinlich und wenn doch, hätte ich ihn bestimmt zurückdatiert. ?
Das habe ich gefunden:
Ian Styx am |
JA, sehr gut! Danke!
Das scheint das zu bestätigen, auch wenn kein Eintrag zwischen 1°° und 2°° dabei ist. Denn immer wenn einer so ist und als startender Monat daherkommt, verzählt es sich in Folge bis zum letzen Monat mit Muster, nicht jeweils +1 verschoben im nächsten, denn wir haben ja 2011 mehrere Monate hintereinander die das genau zeigen.
Bitte jetzt ausführen! Jetzt bin ich sehr gespannt!
Beat Post author am |
o.k. functions_entries.inc.php angepasst und hochgeladen.
Ian Styx am |
Mir ist übel..! ?
Den einzigen Schluss den ich daraus ziehen kann ist, alles ist gut! Kein Grund für irgendwelche Änderungen im code. Es wird auch nicht falsch gezählt. Das einzige was gelitten hat, ist unsere Zeit und der Hirnschmalz der dafür draufgegangen ist.
Setze sie - und das ist eben das Gute. denn jetzt hast du ja bereits eine Liste die du schnell abarbeiten kannst - zurück nach dem jetzt gültigen Offset und alles sollte gut sein. Das ist eben nicht automagisch zu erledigen, sondern eine Folge des Offsetwechsels.
Oder ⁉
Beat Post author am |
❓
Also bei mir sieht es noch genau gleich (falsch) aus, wie zuvor. Muss ich den Browser-Cache leeren um eine Verbesserung zu sehen?
Ian Styx am |
Hast du meinen vorigen Comment gelesen?
Ich kam zum Schluss das kein Fehler vorliegt. Der jetzige Code ist so geschrieben, dass er nur ordentlich mit einem einmal gesetzten Offset arbeitet. Er hat keine Absicht Offsetwechsel selbst erzählerisch zu reparieren. Diese Nahtstellen bei einem Wechsel des Offsets müssen daher (immer) von Hand korrigiert werden. Fertig.
Ich könnte mir auch gut vorstellen, dass ein Teil der History Problematik ebenso damit zusammenhängt.
Beat Post author am |
Ich verstehe es nicht.
Erkläre mir doch bitte, wieso im November 2013 Archiv 7 Beiträge gezählt aber nur deren 6 aufgelistet werden.
Ian Styx am |
Weil der Dezember Eintrag "Lang ists her" ein falsches Offset hat. 7 wäre richtig für den November, inklusive des Lang ists her Eintrags
Dezember: 17 Einträge mit echten 17
November: 7 Einträge mit echten 7
Verwirrend ist wahrscheinlich die Rückwärt/Vorwärtsportierung was wohl daran liegt dass der Zähler rückwärts arbeitet
und die timestamps minus des offsets geformt werden.
Nachtrag: Wenn ich bei mir offset 2 eingebe, sieht das genauso aus wie bei dir.
Nachtrag 2: Genau dieser Richtungswechsel aufwärts / abwärts je nach Zähler und Ausgabe sind das total Verwirrende. Besser ist es sich an das Datum zu halten. Du hast den Artikel am 30. November um 23:11 geschrieben. Also eindeutig ein November Artikel. In die Datenbank wurde er durch das damalige Offset +1 also um -1 zurück als timestamp konvertiert und eingetragen, also 22:11. Jetzt aber wird aus 22:11 mit +2 offset schon der nächste Monat. Alles klar ⁉ ?
Nachtrag 3: Jetzt zur Frage, warum er eigentlich falsch zählt. Der Zähler fragt in dem loop JahrMonat aus dem timestamp ab und zählt die gleichen als Counter hoch. Das ist das was als Zahl ausgegeben wird. Die entries dieses Monats werden aber durch eine echte Abfrage an anderer Stelle gebildet und nicht durch die
falscheZählerZahl in der Folge bestimmt.Nachtrag 4: Das artet ja zum comic aus und erinnert mich stark an "Es greent so green - she's got it. she's got it!". Wir haben also immer falsch herum gedacht, jedenfalls ich! Der Zähler ist nicht falsch, sondern richtig. Aber die Einträge sind falsch und zwar durch den Offsetwechsel. So herum macht es erst Sinn. Und alles kann man durch das Datum herleiten, so wie in Nachtrag 2 erklärt.
Ich denke schreibend, also werde ich! Jetzt besser? ?
Beat Post author am |
Vielen Dank für die grosse Mühe, welche Du Dir für die Erlärung(en) gemacht hast. Ich gebe zu, dass ich es nicht vollständig verstanden habe, doch das ist auch nicht so wichtig.
Meine Sicht ist aktuell wie folgt: www.beatsblog.ch hat ein Problem mit allen Beiträgen, die eine Eintragszeit zwischen 00:00 und 02:00 ausgeben. Diesen kann ich nicht trauen. In >95% der Fälle sind diese falsch, denn sie wurden ursprünglich am Vortag geschrieben und gehörten demzufolge eben zurückdatiert. Es gibt dann aber noch die <5% der Fälle, die richtig sind in dem Sinne, dass sie entweder tatsächlich kurz nach Mitternacht geschrieben wurden oder wie z.B. der Beitrag /2276-Italien-Radreise-2011.html (TimeStamp: 01.06.2011 00:01), welcher ganz bewusst auf diesen Zeitpunkt gespeichert wurde.
Ich bin leider kein SQL-DB-Crack und kenne auch keinen. Hilfreich wäre eine Auflistung aller Beiträge, die eben einen Zeitstempel zwischen 00:00 und 02:00 Uhr tragen. So könnte ich diese gezielt öffnen, Datum und Zeit ändern und wieder abspeichern. Das werden hunderte von Beiträgen sein... Da der timestamp jedoch eine absolute Zahl ist, die (vermutlich) irgendwie von einem Nullpunkt her errechnet wird, sehe ich keine Chance via DB-Abfrage zu einer solchen Liste zu kommen.
In einem ersten Schritt habe ich nun mal die monatsübergreifenden Beiträge aus dem Kommentar #6933 zurückdatiert und somit stimmt zumindest das Monatsarchiv wieder.
Für die Zukunft denke ich, dass ich an verregneten Tagen X Stunden investieren werde und alle > 2'500 Beiträge via "Einträge bearbeiten" überprüfen und gegebenenfalls korrigieren werde. Tja... eine bessere Idee habe ich nicht.
Ian Styx am |
An die Nachkommen!
Solltet ihr je in Versuchung kommen uns zu folgen und nun mehr nicht schlafen können, da ihr die Auflösung verpasst habt, hier (und in den Kommentaren) geht es weiter: https://www.blog.dokumenzi.ch/2643-+1-Std.-Zeitversatz.html
Beat Post author am |
Heute wieder ein leeres history-daylist.dat auf www.beatsblog.ch. TimeStamp: 02:00:28. Gemäss Logfile war dieser Zugriff der Auslöser:
Habe das daylist.dat jetzt gelöscht um wieder eine Anzeige zu erhalten.