nicht angemeldet
Tach!
Du überlässt das Zeitzonenhandling dem DMBS, verwendest TIMESTAMPs und teilst beim Verbindungsaufbau immer mit, welche Zeitzone du verwendest.
Was für ein Kommando muss ich da jetzt noch darunter schreiben, um meine gewünschte Zeitzone festzulegen?
Soweit ich weiß, geht das mit einem Statement SET time_zone = timezone. Als Wert nimmst du sowas wie 'Europe/Berlin'. Der muss bekannt sein, aber üblicherweise reicht es, wenn du einen der allgemeinen Unix-Timezone-Datenbank-Werte angibst. Sie müssten mit denne übereinstimmen, die auch PHP kennt: [llink:http://www.php.net/manual/en/timezones.php@title=List of Supported Timezones].
Und wäre das dann so, dass wenn ein Zeitpunkt als 14:00 UTC gespeichrt ist und ich hier zB. Athen als Zeitzone nehme, dann beim Abruf ein 17:00 ausgegeben wird?
So ist das, zumindest zur Sommerzeit. So funktioniert der Unix-Timestamp, so funktioniert der TIMESTAMP unter MySQL.
Du kannst also durchaus TIMESTAMP nehmen, beim Verbindungsaufbau deine Zeitzone festlegen und dann mit NOW() arbeiten. Intern abgelegt wird dann der zugehörige UTC-Wert.
Es heißt dauernd, dass beim Timestamp in UTC gespeichrt wird. Aber wie kann das sein? Meine Timestamps sind immer aus meiner Zeitzone, also momentan mitteleuropäische Sommerzeit.
Die aktuelle Zeitzone ist dem System bekannt, wenn du sie ordentlich konfiguriert hast (oder auch der Systemadmin).
Von einer UTC Speicherung sehe ich da weit und breit nichts. Wenn Timestamps in UTC speichern und ich erstelle um 18:00 Uhr einen neuen Datensatz, dann müsste doch beim Timestamp ein 16:00 Uhr stehen!?
Beim gespeicherten Wert. Wenn du dir den aber anschauen willst, bekommst du ihn vermutlich gleich wieder in Lokalzeit umgerechnet.
Du kannst das mit PHP nachvollziehen. Nimm date_default_timezone_set() und stell dir da irgendwas ein. Erzeuge mit mktime() einen Timestamp und schau dir den entstehenden Integer an. Stell nun eine andere Zeitzone ein und gib dieselbe Zeit aber umgerechnet auf diese Zeitzone ein. Der entstehende Integer-Wert muss derselbe sein. Und nun lässt du dir den Integer-Wert mit gmdate() formatiert ausgeben, dann siehst du die Zeit in UTC. Die gm*-Date/Time-Funktionen arbeiten immer auf UTC-Basis.
Wenn ich mit phpMyAdmin eine Timestamp Spalte erstelle und weder das Häkchen bei "Current-Timestamp" setze, noch bei den Extras das "auto_increment" einstelle, dann wird _trotzdem_ bei jedem neuen Datensatz automatisch ein Zeotstempel gesetzt. Wieso?
auto_increment wäre auch ungültig und kann gleich gar nicht ungestraft gesetzt werden. Und nun wird's etwas komplex. Früher gab es den Mechanismus nur für das erste TIMESTAMP-Feld. Heute kann er bei einem beliebigen Feld verwendet werden, aber immer nur bei einem. Üblicherweise nimmt man ja gerade ein TIMESTAMP-Feld, weil man dessen Magie gut verwenden kann. Alles zum diesem Automatismus steht unter Automatic Initialization and Updating for TIMESTAMP. Wenn du beim ersten Feld nichts angibst, setzt MySQL per Default DEFAULT CURRENT_TIMESTAMP und ON UPDATE CURRENT_TIMESTAMP. Bei allen weiteren Felder macht es das nicht mehr, selbst wenn das erste Feld keine Magie konfiguriert hat. Wenn du beim ersten Feld einen von beiden Werte explizit angibst, wird der andere nicht gesetzt. Gibst du DEFAULT 0 an, ist die Magie komplett ausgeschaltet.
In deinem Fall würde ich mir die Magie beim Modified-Feld zunutze machen und dieses auf ON UPDATE CURRENT_TIMESTAMP stellen, das Created (wenn es das erste Feld ist) mit DEFAULT 0 konfigurieren und dann lediglich beim INSERT das Created beachten. Ein UPDATE zieht Modified automatisch nach.
dedlfix.