ein counter - und berechnungen

[netti]

Heyho

Ich habe mir nun einen Counter geschreiben. Allerdings habe ich (wies sollte es anders sein) 'nen kleines Problem.
Fähigkeiten des Counters sind Counter gesamt, Besucher gestern und Besucher heute - gespeichert wird in einer db.
Beim Counter funktioniert auch alles, bis auf die Umschaltung zwischen Besucher gestern / heute. Um Punkt Mitternacht, soll das Script die besucher von heute auf gestern schieben und den heute counter auf 0 setzten (natürlich nur, wenn besucher da sind zur ausführung des scripts.).
Soweit so gut, klappt auch.
Zur Funktionsweise: Ich habe mir hierzu überlegt, dass ich das mit timestamps mache, die ja bekanntlich seit dem 1.1.1970 00:00,00 uhr laufen. Jede Sekunde einer mehr. Also nehme ich den timestamp time() und teile ihn durch (60*60*24) um auf die tage seit 1970 zu kommen. Das ganze schneide ich nach dem Komma ab und setzte es in die datenbank für jemweils heute / gestern (gestern ein tag weniger). Sobal die anzahl der Tage umspringt, wird der counter wie oben beschrieben, geleert / verschoben.
Klappt ebenfalls. Allerdings berechnet er mir nicht um 12 uhr nachts, sondern um 2 uhr morgens.
Zur Überprüfung: Wenn ich mit date() einen timestamp aus 0 erzeuge bekomme ich 1.1.1970 um 1:00,00 uhr. Gut, dass schiebe ich auf die Zeitzonen. Aber woher kommt die zweite stunde? wieso ist erst morgens um 2 uhr ein weiterer kompletter tag um und nicht um 1 uhr?

Hier mal ein Beispiel, wie man das Überprüfen kann. EInfach Ausgabe von:

<?php
print date("d. M Y, H:i", 0) ."
"; //timestamp bei 0
print (time()+3600+(3600*1)) / (60 * 60 * 24) ."
"; //timestamp wird anfangs um 2 stunden vergrößert (Die 1 steht für Zeitzone UTC+1)
print (time()+3600) / (60 * 60 * 24) ."
"; //Vergrößerung um eine Stunde
print time() / (60 * 60 * 24) ."
"; //normalzeit
?>

Nun setzt mal den Rechner auf kurz vor 12 startet nen php-server und schaut welches Zeile den Anbruch eines neuen Tag zeigt. Ich verstehe nicht, warum 2 stunden nötig sind...

Das Gesamtproblem sehr schwer zu erklären, wenn es Verständnissprobleme gibt, bitte melden. Mir liegt viel daran, das hier zu verstehen!!

Danke euch sehr!
netswipe

Klappt ebenfalls. Allerdings berechnet er mir nicht um 12 uhr nachts, sondern um 2 uhr morgens.

Sind sich DB und PHP einig über die Uhrzeit?
Für den Fall, dass es um mysql geht:

<?php
$db = mysql_connect('...', '...', '...') or die(mysql_error());

$sql = 'SELECT Now(), Unix_Timestamp(Now())';
$result = mysql_query($sql) or die(mysql_error());
$row = mysql_fetch_row($result);

$now = array();
$now[1] = time();
$now[0] = date('Y-m-d H:i:s', $now[1]);

echo "DB : $row[0] , $row[1]\
\nPHP: $now[0] , $now[1]";
?>

[netti]

DB : 2005-10-22 15:17:40 , 1129987060\
PHP: 2005-10-22 15:17:40 , 1129987060

Ja, völlig identisch. Aber selbst wenn nicht, wird das Script bzw. Abfolge vollständig über php gesteuert.

dann zieh doch einfach die 2 Stunden ab....
also timestamp - 2 * 60 * 60

[netti]

ja mache ich ja auch.

Aber ich verstehe einfach nicht wieso. 2 ist alles andere als logisch. Nur 1 ist sinnvoll! Ich fände es eben toll das zu verstehen... :/

[Basti]

Hi.

Ich verstehe leider dein Problem nicht ganz (wie auch dein letztes, auf das ich geantwortet habe). Auf den ersten Blick sieht mir das jedoch danach aus, dass du hier die Mitteleuropäische Sommerzeit erwartest, jedoch davon ausgehst, dass diese der UTC nur 1 Stunde vorausläuft, obwohl sie eben 2 Stunden vorgeht. Ich würde in dem Fall hier übrigends die Datumsfunktionen von MySQL bemühen.

Basti

Ich würde in dem Fall hier übrigends die Datumsfunktionen von MySQL bemühen.

Und dann auch nicht sowas wie

Sobal die anzahl der Tage umspringt, wird der counter wie oben beschrieben, geleert / verschoben.

machen, sondern die relevanten Datensätze/Aggregate abfragen. Wenn der Index richtig gesetzt ist, tut das überhaupt nicht weh. Daten verschieben, löschen, ändern kannst Du immer noch zu einem (viel) späteren Zeitpunkt.

[netti]

de.wikipedia.org:
Die deutsche Standardzeit ist die Mitteleuropäische Zeit (MEZ, oder auch CET für "Central European Time"), die gleich der UTC plus einer Stunde ist.

Habe ich gelesen - aaaaber: Die nicht richtig Lesenden werden mal wieder bestraft, denn der nächste Satz lautet:

de.wikipedia.org:
Während der Sommerzeit gilt die Mitteleuropäische Sommerzeit (MESZ/CEST), die der UTC plus zwei Stunden entspricht.

Damit hat sich das dann auch erledigt. Entschuldigt meine Unwissenheit und die Tatsache, dass ich nicht richtig geblättert habe. Werde ich mir noch was mit der Winterzeit überlegen müssen. Eine Möglickeit wäre natürlich noch, einfach per getdate() (jahr - einrichtungsjahr des counters) * 365 + tag des jahres.

Was ist im Übrigen der genaue Vorteil der Nutzung von MySQL's eingebauter Zeitfunktion?

Bei der Gelegenheit: Ich glaube es wäre mal ein Forum nicht schlecht, in dem Beiträge nicht gezählt werden, aber auch mal Dinge gefragt werden dürfen, die man ganz einfach vergessen/übersehen hat und bei denen Google nicht viel helfen würde (dies insbesondere mit Blick auf den genannten anderen Beitrag von mir ).

[Zergling-new]

Re: ein counter - und berechnungen

Das Gesamtproblem sehr schwer zu erklären

Eigentlich ist es doch weder schwer zu erklären, noch es zu lösen.
Du willst offenbar täglich ermitteln, wieviele Besucher deine Seite besucht haben.
Ich weiß jetzt nicht auf welchem Speichersystem dein Counter funktionieren soll, Datei oder DB.

Für beides würde ich die date()-Funktion vorschlagen:
date("Y-m-d") liefert dir den aktuellen Tag in der Schreibweise YYYY-MM-DD.
Benutze das doch als Index (Dateinamen bzw. Spalte, die du per WHERE Bedingung ansprichst).

Bei der Dateispeicherung ist das kein Problem, du kannst sie ja schreibend öffnen (wenn sie noch nicht existiert, wird sie neu angelegt), bei MySQL mußt du eben ein UPDATE probieren:

UPDATE counter SET hits = hits + 1 WHERE refDate = UNIX_TIMESTAMP() LIMIT 1

(wenn refDate vom Typ 'Date' ist).

Dann testest du mit mysql_affected_rows() == 1 ob das Update geklappt hat, wenn nicht, hat die WHERE-Bedingung keine Zeile erwischt, daraus folgt es gibt keine, also mußt du sie mit
INSERT INTO counter SET hits = 1, refDate = UNIX_TIMESTAMP()

setzen. Oder hab ich dein Ziel jetzt total verfehlt?

[netti]

nein...genau das meinte ich. Nur, dass ichs mit time() gemacht habe und den auf tage umrechne. Bei jedem Aufruf wird geprüft, ob de rtag in der db noch der selbe ist, wenn nicht wird aktualisiert.

Allein dadurch, dass ichs mit time() gemacht habe hat das "problem" aufgerufen, da ich aus meiner traumwelt gerüttelt wurde, als ich merkte, dass es erst um 1 nen update gibt (ich überlege vorher erst, wie ich etwas umsetzen will und schreibe dann erst drauf los - denke das ist normal). Ich habe nicht dran gedacht, dass die zeitzonen mit einbezogen werden, obwohl das natürlich logisch ist. Jedenfalls habe ich beim anschließenden googlen überlesen, dass mesz 2 stunden vor utc ist im gegensatz zu 1 im winter / mez.

Tja und dafür wollte ich ne erklärung. Ich hätte natürlich auch einfach richtig lesne können *sich-vorn-kopf-hau* ^^

Was ist im Übrigen der genaue Vorteil der Nutzung von MySQL's eingebauter Zeitfunktion?

Dass Mysql im Gegensatz(offensichtlich) zu Dir mit Datum und Uhrzeit umzugehen versteht
Einige Sachen lassen sich dadurch auch kürzer, eleganter, schneller schreiben.
zB SELECT Count(*) FROM foo WHERE Curdate()<=einDatetimeFeld
Datenbankpuristen werden aufheulen, aber die sollten dann auch nicht mysql verwenden.
Andererseits legst Du Dich dann auf Mysql fest. Richtig gekapselt sit aber auch das kein Problem.

[netti]

Was ist im Übrigen der genaue Vorteil der Nutzung von MySQL's eingebauter Zeitfunktion?

Dass Mysql im Gegensatz(offensichtlich) zu Dir mit Datum und Uhrzeit umzugehen versteht
Einige Sachen lassen sich dadurch auch kürzer, eleganter, schneller schreiben.
zB SELECT Count(*) FROM foo WHERE Curdate()<=einDatetimeFeld
Datenbankpuristen werden aufheulen, aber die sollten dann auch nicht mysql verwenden.
Andererseits legst Du Dich dann auf Mysql fest. Richtig gekapselt sit aber auch das kein Problem.

Punkt! Ich hab null plan von den kompletten potenzen von mysql. Sollte ich mich mal einarbeiten. Aber vorher will ich gern mein php noch verfeinern.
Was nicht heißt, dass ich mit mysql nicht umgehen kann.
Nun gut. Danke für die antwort. Denke mal das thema ist erledigt, oder?