Es ist mal wieder der running Gag, das Schaltjahr. 🤬Ich finde durchaus einen workaround für heute, aber ... es scheint wurmstichig allemal wenn ich weiter ins Jahr vorschaue. Das Problem ist, dass ich mich auf die Daten nicht verlassen kann um dem Problem grundlegend auf den Grund zu gehen, denn immer wieder purzeln einzelne 23.59 Uhr Einträge hinein, die die Verlässlichkeit wegen dem möglichen Offset verunsichern. Jage ich also Gespenster oder Reales? 👻
Beat Post author am |
Ein Workaround via DB-Tabelle-Export-Ersetzen-Import geht vermutlich auch nicht, da meines Wissens die Veröffentlichungszeiten der entries nicht in hh:mm sondern in einem anderen Zahlensalat gespeichert sind. Ersetze 23:59 durch 22:59 wird deshalb wohl nicht gehen.
Ich warte mal ab, denn vielleicht sieht die History-Welt morgen schon wieder anders aus. 😉
Sie sind als UNIX Timestamp - als der Anzahl Sekunden seit 01.01.1970 gespeichert und das als UTC time, wo dann der offset dazu bzw abkommt und berechnet wird. Wir hatten ja den offset Schlamassel mit dem historischen und aktuellem Server offset(s) und den daraus resultierenden falschen Berechnungen von deinen Einträgen zwischen 23:00 und 23:59, welches wir dann korrigiert hatten. (Ob das nun hier (Server) und auch da (Server) und/oder auch noch bei mir (mit meinen test Daten) ergibt allemal so viel Unsicherheiten, dass mir der Kopf raucht.) Ich rechne ja mit plus 366 bzw plus 365 Tagen je nach Schaltjahr über einen range von X Jahren um die richtigen timestamp ranges zwischen 00.00 und 23:59 für den entries fetch zu berechnen für all diese Tage.
Also irgendwas mache ich nicht richtig, mit der Unsicherheit über die Verlässlichkeit der zugrunde liegenden Daten.
Das kann ich dir jetzt schon sagen (mit älterem Datensatz) :
2024-02-29 bool(false) = 365 Tage
Fr., 01.03.2019 23:36 Tag 7 - nach Gambassi Terme
Do., 01.03.2018 14:06 Saisonstart?
Mo., 29.02.2016 21:46 mal etwas anderes
Sa., 01.03.2014 23:59 Fehlstart?
Mi., 29.02.2012 11:46 Geduldspiel
Mo., 01.03.2010 23:59 Hammer-Februar!
So., 01.03.2009 20:31 ZüriCarneval
Mi., 01.03.2006 22:29 von Radtouren träumen
Mi., 01.03.2006 20:13 die Sache mit den Umlauten
Mi., 01.03.2006 09:29 NEU: Domaine-Registrierung [...]
2024-03-01 bool(true) = 366 Tage
Fr., 01.03.2019 23:36 Tag 7 - nach Gambassi Terme
Do., 01.03.2018 14:06 Saisonstart?
Sa., 01.03.2014 23:59 Fehlstart?
Do., 01.03.2012 23:38 Strassenzulassung
Mo., 01.03.2010 23:59 Hammer-Februar!
So., 01.03.2009 20:31 ZüriCarneval
Sa., 01.03.2008 22:36 Februar-März
Sa., 01.03.2008 22:05 Emma sagt nein
Mi., 01.03.2006 22:29 von Radtouren träumen
Mi., 01.03.2006 20:13 die Sache mit den Umlauten
Mi., 01.03.2006 09:29 NEU: Domaine-Registrierung [...]
Es ist natürlich auch die Frage was man da (29. Feb,) eigentlich erwartet..., denn die Schaltjahre ergeben natürlich den 29. und die anderen den 01.
Schaltjahre sind 2024, 2020, 2016, 2012, 2008.
Wie würdest du das sehen?
Beat Post author am |
Es ist natürlich auch die Frage was man da (29. Feb,) eigentlich erwartet..., denn die Schaltjahre ergeben natürlich den 29. und die anderen den 01.
In der Theorie würde ich sagen, dass der 29.02. eben genau der 29.02. ist und somit nur Beiträge aus den entsprechenden Schaltjahren angezeigt werden. Doch das würde wohl zu viel Aufwand für einen einzelnen Tag -der nur alle vier Jahre mal auftaucht- bedeuten. Ist wohl die Mühe nicht wert.
Ich kann sehr gut mit der obigen Anzeige für den 29.02. leben, wenn danach am 01.03. die Anzeige wieder stimmt.
Es ist mehr die Frage ob explizit oder nicht, denn stimmen tun m.E. ja auch die 01.03 Anzeigen, denn sie sind in den normalen Jahren eben genau 1, 2, 3, x Jahre zurück und daher nicht unbedingt falsch. Anzunehmenderweise sind auch generell Blogbeiträge am 29 in Schaltjahren höchstwahrscheinlich weniger als 1. März Einträge zu finden... schon allein quantitativ, so dass es anzeigenmäßig wohl eher vorkommt, dass es am 29. zu leeren Anzeigen kommt. ( Außer bei Herrn Menzi. Und das ist toll! 😄)
Die 01.03. Einträge am 29. Feb. zu unterdrücken bzw herauszurechnen ist aber kein Ding. Es wird ja außerdem gecached, aber spielt selbst ohne keine wesentliche Rolle für die Routinen.
Also, wie belieben zu haben... 😉?
Beat Post author am |
Also wenn ich wünschen kann, so nehme ich Tor 2! 😁 denn der 29.02. ist eben nicht der 01.03. 😉
Nur zur Info... Ich habe noch ein paar Tage daran weitergebastelt um den test-case Ungereimheiten auf die Spur zu kommen. Deshalb sind noch allerlei Verbesserungen entstanden. ( Vorher konnte ich mich Anderem nicht zuwenden...🙃)
Ich glaube, dass diese Verbesserungen dich im aktuellen Schaltjahr nicht treffen werden, bevor das nächste Styx mit dem letzten Stand released wird. Solltest du trotzdem herumspielen wollen, müsstest du allerdings diesmal auch die Sprachdateien [UTF-8/de] bzw [en] erneuern.
Beat Post author am |
O.K. Habe hier und auf beatsblog.ch die neuen Dateien aufgespielt. 👍
Ich hoffe das war meinerseits nicht missverständlich ausgedrückt, denn das finetuning etc betraf grundlegend nur Daten mit gewisser Entfernung, wären also wohl nicht vor nächstem Update aufgetreten ...😊
Beat Post author am |
Kein Thema. Ich habe es schon richtig verstanden. Hatte einfach Zeit und Lust um die Änderungen aufzuspielen. 😉👋
Beat Post author am |
Oh! Das history-Plugin hat den Sprung ins neue Jahr nicht sauber hingekriegt. Es werden vorwiegend Beiträge des 31.12. und wenige 01.01. angezaigt.
Das Löschen der history_daylist.dat hat leider keine Verbesserung gebracht.
Ian Styx am |
Oh du fröhliche .... Schönes Neues Jahr!
Es ist mal wieder der running Gag, das Schaltjahr. 🤬Ich finde durchaus einen workaround für heute, aber ... es scheint wurmstichig allemal wenn ich weiter ins Jahr vorschaue. Das Problem ist, dass ich mich auf die Daten nicht verlassen kann um dem Problem grundlegend auf den Grund zu gehen, denn immer wieder purzeln einzelne 23.59 Uhr Einträge hinein, die die Verlässlichkeit wegen dem möglichen Offset verunsichern. Jage ich also Gespenster oder Reales? 👻
Beat Post author am |
Ein Workaround via DB-Tabelle-Export-Ersetzen-Import geht vermutlich auch nicht, da meines Wissens die Veröffentlichungszeiten der entries nicht in hh:mm sondern in einem anderen Zahlensalat gespeichert sind. Ersetze 23:59 durch 22:59 wird deshalb wohl nicht gehen.
Ich warte mal ab, denn vielleicht sieht die History-Welt morgen schon wieder anders aus. 😉
Ian Styx am |
Sie sind als UNIX Timestamp - als der Anzahl Sekunden seit 01.01.1970 gespeichert und das als UTC time, wo dann der offset dazu bzw abkommt und berechnet wird. Wir hatten ja den offset Schlamassel mit dem historischen und aktuellem Server offset(s) und den daraus resultierenden falschen Berechnungen von deinen Einträgen zwischen 23:00 und 23:59, welches wir dann korrigiert hatten. (Ob das nun hier (Server) und auch da (Server) und/oder auch noch bei mir (mit meinen test Daten) ergibt allemal so viel Unsicherheiten, dass mir der Kopf raucht.) Ich rechne ja mit plus 366 bzw plus 365 Tagen je nach Schaltjahr über einen range von X Jahren um die richtigen timestamp ranges zwischen 00.00 und 23:59 für den entries fetch zu berechnen für all diese Tage.
Also irgendwas mache ich nicht richtig, mit der Unsicherheit über die Verlässlichkeit der zugrunde liegenden Daten.
Ian Styx am |
Ping! Ich habe dir was hinterlassen.😉
Beat Post author am |
👍 Funktioniert! ✔ Vielen Dank!
Und ja, ich habe beim auto-update-Test vorher das zip von V4.3.2 gelöscht.
Ian Styx am |
Super! Ich habe es für nächstes Styx 4.3.3 oder 4.4 committet. 😊
Ian Styx am |
Ping. (Nachtrag.)
Beat Post author am |
Habe das neuste serendipity_plugin_history.php aufgespielt, das history_daylist.dat gelöscht und neu generiert. Sieht gut aus. 👍
Ian Styx am |
Ich habe es mal Plugin mit Langzeitbeobachtung betitelt. Wir werden aus diesem Modus wohl nicht herauskommen... 😁
Beat Post author am |
Mal sehen, was am 29.02. und 01.03. angezeigt wird...😏
Ian Styx am |
Gute Frage! ( rumspiel... )
Das kann ich dir jetzt schon sagen (mit älterem Datensatz) :
Es ist natürlich auch die Frage was man da (29. Feb,) eigentlich erwartet..., denn die Schaltjahre ergeben natürlich den 29. und die anderen den 01.
Schaltjahre sind 2024, 2020, 2016, 2012, 2008.
Wie würdest du das sehen?
Beat Post author am |
In der Theorie würde ich sagen, dass der 29.02. eben genau der 29.02. ist und somit nur Beiträge aus den entsprechenden Schaltjahren angezeigt werden. Doch das würde wohl zu viel Aufwand für einen einzelnen Tag -der nur alle vier Jahre mal auftaucht- bedeuten. Ist wohl die Mühe nicht wert.
Ich kann sehr gut mit der obigen Anzeige für den 29.02. leben, wenn danach am 01.03. die Anzeige wieder stimmt.
Ian Styx am |
Es ist mehr die Frage ob explizit oder nicht, denn stimmen tun m.E. ja auch die 01.03 Anzeigen, denn sie sind in den normalen Jahren eben genau 1, 2, 3, x Jahre zurück und daher nicht unbedingt falsch. Anzunehmenderweise sind auch generell Blogbeiträge am 29 in Schaltjahren höchstwahrscheinlich weniger als 1. März Einträge zu finden... schon allein quantitativ, so dass es anzeigenmäßig wohl eher vorkommt, dass es am 29. zu leeren Anzeigen kommt. ( Außer bei Herrn Menzi. Und das ist toll! 😄)
Die 01.03. Einträge am 29. Feb. zu unterdrücken bzw herauszurechnen ist aber kein Ding. Es wird ja außerdem gecached, aber spielt selbst ohne keine wesentliche Rolle für die Routinen.
Also, wie belieben zu haben... 😉?
Beat Post author am |
Also wenn ich wünschen kann, so nehme ich Tor 2! 😁 denn der 29.02. ist eben nicht der 01.03. 😉
Ian Styx am |
Ping! ( Simsalabim. 😊)
Beat Post author am |
O.K. Nächste Version des serendipity_plugin_history.php aufgespielt. Der 29.02.2024 kann kommen! 😉
Ian Styx am |
Nur zur Info... Ich habe noch ein paar Tage daran weitergebastelt um den test-case Ungereimheiten auf die Spur zu kommen. Deshalb sind noch allerlei Verbesserungen entstanden. ( Vorher konnte ich mich Anderem nicht zuwenden...🙃)
Ich glaube, dass diese Verbesserungen dich im aktuellen Schaltjahr nicht treffen werden, bevor das nächste Styx mit dem letzten Stand released wird. Solltest du trotzdem herumspielen wollen, müsstest du allerdings diesmal auch die Sprachdateien [UTF-8/de] bzw [en] erneuern.
Beat Post author am |
O.K. Habe hier und auf beatsblog.ch die neuen Dateien aufgespielt. 👍
Ian Styx am |
Ich hoffe das war meinerseits nicht missverständlich ausgedrückt, denn das finetuning etc betraf grundlegend nur Daten mit gewisser Entfernung, wären also wohl nicht vor nächstem Update aufgetreten ...😊
Beat Post author am |
Kein Thema. Ich habe es schon richtig verstanden. Hatte einfach Zeit und Lust um die Änderungen aufzuspielen. 😉👋
Beat Post author am |
Die Spannung steigt...
Ian Styx am |
😊 Ja... denn die 4.4 ist nah... sehr nah!
Hoffe alles ist gut soweit und fließt verstopfungsfrei in seinem vorgegebenen Keise!
Ian Styx am |
👍nur echte twentyniners! 😉