[3.3] [CDB] LF who was here 2 (Wer war da?)

[LukeWCS]

Merci Kirk!

@stefan-franz

Um das von .com auch hierher zu holen: ich habe mir das schon mal angeschaut, für deinen Wunsch muss ich etliche Dinge anpassen, denn es war bei NVWWH oder LFWWH nie vorgesehen, das auch die Anzahl der sichtbaren Benutzer abgeschaltet werden kann. Also wäre dein Wunsch eigentlich zu speziell gewesen, aber er passt gut ins Konzept und ist im Endeffekt auch konsequent, denn die anderen 3 Kategorien können auch abgeschaltet werden.

Bis beta2 soweit ist, kannst Kirk's oder Wolkenbuch's Workaround nutzen.

[LukeWCS]

beta2 online.

Alle Bilder von 1.5.1 auf 2.0.0-beta2 aktualisiert.

[stefan-franz]

Vielen lieben Dank, LukeWCS, für das Programmieren meines Wunsches. Läuft einwandfrei!

[LukeWCS]

Hallo Wolkenbruch

Als Unterschied fällt mir nur auf, das die anderen alle auf Servern in Deutschland und ich auf einem Server in den USA liege.

Ich brauche Infos von dir. Zur Zeit untersuche ich das Zeitzonen-Problem und ich denke ich habe den Fehler gefunden. Wenn sich das bei dir bestätigt, dann hat Anvar da einen Fehler in seiner Formel zur Berechnung des Lösch-Zeitstempels. Es sieht so aus, als hätte er da eine Korrektur für den Fall eingebaut, das die Zeitzonen von PHP und phpBB unterschiedlich sind, die jedoch unmittelbar nach einer Zeitumstellung gar nicht greift. Und genau das dürfte bei dir der Fall sein, da dein Server in den USA betrieben wird.

Darum musst du bei dir kurzfristig eine Debug Funktion einbauen, die ich für dieses Problem ausgearbeitet habe. Dieser Codeblock ist ein Teil meiner Testumgebung mit der ich z.Z. versuche, diese Situation zu simulieren.

Folgende Datei muss geändert werden:

lukewcs\whowashere\core\who_was_here.php

Dort suchst du nach:

Code: Alles auswählen

	public function display()
	{

Direkt unter der öffnenden Klammer den folgenden Codeblock einfügen und die Datei speichern:

Code: Alles auswählen

$timeformat = "Y-m-d  H:i:s (e [T] P [\D\S\T=I])";
$timezone = new \DateTimeZone($this->config['board_timezone']);
foreach ([1553993999, 1553994001, 1554069601, 1554073201, 1554156001] as $timestamp)
{
	echo $timestamp . ' ' . $this->user->format_date($timestamp, $timeformat) . ' >> $this->user->format_date($timestamp, $timeformat)<br>'; 
	echo $timestamp . ' ' . date($timeformat, $timestamp) . ' >> date($timeformat, $timestamp)<br>'; 
	$prune_timestamp = $this->user->get_timestamp_from_format('Y-m-d H:i:s', date('Y', $timestamp) . '-' . date('m', $timestamp) . '-' . date('d', $timestamp) . ' 00:00:00', $timezone);
	echo $prune_timestamp . ' ' . $this->user->format_date($prune_timestamp, $timeformat) . ' >> $this->user->format_date($prune_timestamp, $timeformat)<br>'; 
	if ($prune_timestamp < $timestamp - 86400)
	{
		echo '$prune_timestamp < $timestamp - 86400 >> $prune_timestamp += 86400<br>';
		$prune_timestamp += 86400;
	}
	else
	{
		if ($prune_timestamp > $timestamp)
		{
			echo '$prune_timestamp > $timestamp >> $prune_timestamp -= 86400<br>';
			$prune_timestamp -= 86400;
		}
		else
		{
			echo '$prune_timestamp <= $timestamp >><br>';
		}
	}
	echo $prune_timestamp . ' ' . $this->user->format_date($prune_timestamp, $timeformat) . ' >> $this->user->format_date($prune_timestamp, $timeformat)<br>'; 
	echo '---<br>';
}

Jetzt öffne den Forenindex und kopiere ganz oben alles bis zur letzten Markierung (---) und füge es hier ein. Dann den Codeblock wieder entfernen.

[Wolkenbruch]

Danke für die Mühe die Du Dir machst.

Bis zum 31.12.2019 ist ja noch Zeit, bis dahin hast du das ganze bestimmt im Griff.

Es stimmt, als das Forum noch in Deutschland gehostet wurde gab es diesen Fehler nie. Erst seitdem ich bei einem Hoster in den USA bin ist es mir aufgefallen.

[LukeWCS]

Danke für die Mühe die Du Dir machst.

Ich gehe jedem gemeldeten Fehler nach, auch wenn er so "harmlos" ist wie dieser. Ein Fehler ist ein Fehler und wird behoben, sofern möglich. Der erste Schritt zur Behebung eines Fehlers ist natürlich immer, diesen zu melden. Das hast du getan und nun verfolge ich das auch.

Bis zum 31.12.2019 ist ja noch Zeit, bis dahin hast du das ganze bestimmt im Griff.

Wenn du mir die Infos lieferst die ich brauche, dann stehen die Chancen gut.

Und du meinst wohl bis zum 27.10.2019, denn da steht die nächste Zeitumstellung an. Und da tritt der Fehler gleich doppelt in Erscheinung, das heisst die Bereinigung wird dann gleich zweimal kurz hintereinander ausgeführt, was dann noch deutlicher für Irritationen sorgen wird. Zumindest bei den Besuchern die dann zwischen 23:00 und 01:00 im Forum unterwegs sind.

Es stimmt, als das Forum noch in Deutschland gehostet wurde gab es diesen Fehler nie. Erst seitdem ich bei einem Hoster in den USA bin ist es mir aufgefallen.

Der Fehler war da auch schon vorhanden, also bereits bei NVWWH, er hatte aber nie Auswirkungen, weil die Zeitzonen beider Bereiche, also PHP und phpBB stets identisch waren. Jetzt hat deine PHP Umgebung aber mit Sicherheit eine ganz andere Zeitzone als dein phpBB und darum tritt der Fehler jetzt auch auf. Weil, ein amerikanischer Hoster hat wohl kaum eine europäische Zeitzone definiert.

edit: Ach was freue ich mich, wenn dieser Schwachsinn mit der Zeitumstellung 2021 endlich abgeschafft wird.

[canonknipser]

mit der Zeitumstellung 2021 endlich abgeschafft wird.

Nur in der EU.

Aber sei froh, dass es hier so einfach ist. Und das wir nur drei Zeitzonen in der EU haben (die franz. Überseegebiete mal ausgenommen)
In den USA hast du Staaten, die nehmen an der Sommerzeitumstellung teil (fast alle) oder nicht (z.B. Arizona, Hawaii). Wenn nicht, kann es aber sein, dass ein Teil des Staatsgebietes doch dran teil nimmt (Navajo-Stammesgebiete in Arizona), aber darin ein Teil doch wieder nicht, nämlich die Hopi-Stammesgebiete innerhalb der Navajo-Stammesgebiete (wobei es da auch wieder Navajo-Gebiete innerhalb der Hopi-Gebiete gibt, die wieder Sommerzeit haben ...) https://www.timeanddate.com/time/us/ari ... tml:cookie:

also PHP und phpBB stets identisch waren

Darauf konnte man sich nie verlassen - es gibt auch hierzulande Hoster, die in UTC hosten (was in meinen Augen das sinnvollste ist), Zeitzoneneinstellung und Zeitumstellung ist dann immer eine Aufgabe der installierten Software.

[LukeWCS]

Nur in der EU.

Leider.

Aber sei froh, dass es hier so einfach ist. Und das wir nur drei Zeitzonen in der EU haben (die franz. Überseegebiete mal ausgenommen)
In den USA hast du Staaten, die nehmen an der Sommerzeitumstellung teil (fast alle) oder nicht (z.B. Arizona, Hawaii). Wenn nicht, kann es aber sein, dass ein Teil des Staatsgebietes doch dran teil nimmt (Navajo-Stammesgebiete in Arizona), aber darin ein Teil doch wieder nicht, nämlich die Hopi-Stammesgebiete innerhalb der Navajo-Stammesgebiete (wobei es da auch wieder Navajo-Gebiete innerhalb der Hopi-Gebiete gibt, die wieder Sommerzeit haben ...)

Schön, wenn sich alle so einig sind.

Darauf konnte man sich nie verlassen - es gibt auch hierzulande Hoster, die in UTC hosten (was in meinen Augen das sinnvollste ist), Zeitzoneneinstellung und Zeitumstellung ist dann immer eine Aufgabe der installierten Software.

Ahja. Um so wichtiger ist es, den Fehler zu beheben. Dann zählt nur noch was in phpBB eingestellt ist und gut ist. Dann muss uns die Zeitzone des Hosters nicht mehr kümmern. Wegen UTC: Vermutlich weil es zu viele potentielle Probleme mit nicht angepasster Software gibt, entscheiden sich - zumindest manche - deutsche Hoster für eine Angleichung der Zeitzone.

[Wolkenbruch]

@LukeWCS

So, das kam heraus

Code: Alles auswählen

1553993999 2019-03-31 01:59:59 (Europe/Berlin [CET] +01:00 [DST=0]) >> $this->user->format_date($timestamp, $timeformat)
1553993999 2019-03-31 00:59:59 (UTC [UTC] +00:00 [DST=0]) >> date($timeformat, $timestamp)
1553986800 2019-03-31 00:00:00 (Europe/Berlin [CET] +01:00 [DST=0]) >> $this->user->format_date($prune_timestamp, $timeformat)
$prune_timestamp <= $timestamp >>
1553986800 2019-03-31 00:00:00 (Europe/Berlin [CET] +01:00 [DST=0]) >> $this->user->format_date($prune_timestamp, $timeformat)
---
1553994001 2019-03-31 03:00:01 (Europe/Berlin [CEST] +02:00 [DST=1]) >> $this->user->format_date($timestamp, $timeformat)
1553994001 2019-03-31 01:00:01 (UTC [UTC] +00:00 [DST=0]) >> date($timeformat, $timestamp)
1553986800 2019-03-31 00:00:00 (Europe/Berlin [CET] +01:00 [DST=0]) >> $this->user->format_date($prune_timestamp, $timeformat)
$prune_timestamp <= $timestamp >>
1553986800 2019-03-31 00:00:00 (Europe/Berlin [CET] +01:00 [DST=0]) >> $this->user->format_date($prune_timestamp, $timeformat)
---
1554069601 2019-04-01 00:00:01 (Europe/Berlin [CEST] +02:00 [DST=1]) >> $this->user->format_date($timestamp, $timeformat)
1554069601 2019-03-31 22:00:01 (UTC [UTC] +00:00 [DST=0]) >> date($timeformat, $timestamp)
1553986800 2019-03-31 00:00:00 (Europe/Berlin [CET] +01:00 [DST=0]) >> $this->user->format_date($prune_timestamp, $timeformat)
$prune_timestamp <= $timestamp >>
1553986800 2019-03-31 00:00:00 (Europe/Berlin [CET] +01:00 [DST=0]) >> $this->user->format_date($prune_timestamp, $timeformat)
---
1554073201 2019-04-01 01:00:01 (Europe/Berlin [CEST] +02:00 [DST=1]) >> $this->user->format_date($timestamp, $timeformat)
1554073201 2019-03-31 23:00:01 (UTC [UTC] +00:00 [DST=0]) >> date($timeformat, $timestamp)
1553986800 2019-03-31 00:00:00 (Europe/Berlin [CET] +01:00 [DST=0]) >> $this->user->format_date($prune_timestamp, $timeformat)
$prune_timestamp < $timestamp - 86400 >> $prune_timestamp += 86400
1554073200 2019-04-01 01:00:00 (Europe/Berlin [CEST] +02:00 [DST=1]) >> $this->user->format_date($prune_timestamp, $timeformat)
---
1554156001 2019-04-02 00:00:01 (Europe/Berlin [CEST] +02:00 [DST=1]) >> $this->user->format_date($timestamp, $timeformat)
1554156001 2019-04-01 22:00:01 (UTC [UTC] +00:00 [DST=0]) >> date($timeformat, $timestamp)
1554069600 2019-04-01 00:00:00 (Europe/Berlin [CEST] +02:00 [DST=1]) >> $this->user->format_date($prune_timestamp, $timeformat)
$prune_timestamp < $timestamp - 86400 >> $prune_timestamp += 86400
1554156000 2019-04-02 00:00:00 (Europe/Berlin [CEST] +02:00 [DST=1]) >> $this->user->format_date($prune_timestamp, $timeformat)

[LukeWCS]

@LukeWCS

So, das kam heraus

Danke.

Das bringt mich weiter. Dein Hoster hat also UTC (Zeitzone 0) eingestellt. Das habe ich nun in meine lokale Testumgebung übernommen und mal die Simulation der letzten Zeitumstellung (auf Sommerzeit) laufen lassen. Es verhält sich tatsächlich alles so, wie ich es vermutet habe. Das folgende Bild zeigt das Ergebnis. Lokal arbeite ich zusätzlich mit Farben, damit ich Fehler sofort sehe und nicht erst suchen muss.

[ externes Bild ]

Bei Block 4 sieht man den primären Fehler. Das Datum des Lösch-Stempels ist falsch. Bei dir hatte das am 1.4.2019 um 00:00:00 zur Folge, das er keine Bereinigung durchgeführt hat, weil der berechnete Zeitstempel nicht vom gespeicherten abwich. Denn der berechnete entsprach exakt dem Zeitstempel vom Vortag. Das war also der Grund warum die Umschaltung auf den neuen Tag nicht erfolgte.

Block 5 zeigt den sekundären Fehler. Das heisst die Uhrzeit des Lösch-Stempels ist falsch. Diese muss - umgerechnet auf die lokale Zeitzone - immer 00:00:00 betragen. Aber zumindest war der berechnete Zeitstempel anders als der gespeicherte und deshalb wurde um 01:00:00 auf den neuen Tag umgeschaltet, sprich die Bereinigung durchgeführt. Durch die falsche Uhrzeit hat er aber nicht nur alle Einträge aus der Besucher-Tabelle gelöscht die vor 00:00:00 online waren, sondern auch alle die vor 01:00:00 online waren. Dadurch fehlten an diesem Tag effektiv alle Besucher in der Statistik und der Benutzerliste, die zwischen 00:00:00 und 01:00:00 online waren.

Sprich, um kurz nach 01:00:00 dürftest du eine nahezu leere Statistik und leere Benutzerliste gehabt haben. Aber daran wirst du dich vermutlich nicht mehr erinnern können, oder?

Okay, ich habe jetzt genug Infos um damit weiter testen zu können.

edit: Und so sähe die Simulation der bevorstehenden Zeitumstellung (auf Winterzeit) aus.

[ externes Bild ]

Durch den sekundären Fehler würde der neue Tag (nach der Zeitumstellung) schon um 23:00:00 beginnen. Er würde dann also um diese Uhrzeit bereits alles löschen was älter ist. Um 00:00:00 würde er dann wegen dem primären und sekundären Fehler gar nichts machen, weil gespeicherter und berechneter Zeitstempel identisch wäre. Dafür würde er um 01:00:00 nochmal eine Bereinigung durchführen und dann alles löschen, was vor 00:00:00 lag. Das heisst ab 28.10.2019 um 01:00:00 wäre wieder alles korrekt.