nicht angemeldet
Tach!
Das "created" wird bei der Erstellung eines neuen Datensatzes automatisch eingefügt. (Typ:'timestamp', Standard:'CURRENT_TIMESTAMP')
Das "modified" (Typ:'datetime')
Warum nimmst du hier nicht ebenfalls den Typ TIMESTAMP? Abgesehen davon, dass er (derzeit) nur bis ins Jahr 2038 reicht, werden dort genauso wie beim created-Feld keine Zeiten vor 1970 abgelegt. Damit eignet er sich genauso gut oder schlecht für das modified-Feld. Das Jahr-2038-Problem ist eins, das MySQL sowieso lösen muss und dessen Lösung du auch für created benötigst. Deshalb würde ich mir darum grad keine Gedanken machen.
bleibt bei der Erstellung eines neuen Datensatzes leer und bei jeder Veränderung des Datensatzes wird es gemeinsam mit den Änderungen als prepared Statement mittels der SQLi-eigenen Syntax 'VALUES NOW()' eingefügt.
SQLi? Das i in mysqli ist ein reine PHP-Bezeichnung. Das ändert nichts am (My)SQL-Dialekt.
Was ist, wenn mein in Deutschland ansässiger Provider auf die Idee kommt, seine Serverfarm aus Kostengründen von Deutschland nach Tschimbukistan auszulagern und die Serverzeit auf Lokalzeit Tschimbukistan umgestellt wird? Dann entspricht der Zeitstempel ja nicht der mitteleuropäischen Zeit.
Dann hättest du mit TIMESTAMP statt DATETIME ein Problem weniger, denn (siehe Handbuch) TIMESTAMP speichert von sich aus in UTC und rechnet zwischen der aktuellen Zeitzoneneinstellung und UTC um. Wie MySQL mit den Zeitzonen umgeht steht in MySQL Server Time Zone Support. Es gibt also eine Per-Connection-Timezone-Einstellung. Diese Wert steht zunächst auf der Server-Zeitzone.
Wenn dein Hoster nun nach Tschimbukistan umzieht und noch dazu die Server-Zeitzonen auf lokal stellt, bekommst du schon mit deinem created-TIMESTAMP ein Problem, denn dein Client ist in dem Fall ebenfalls ein in Tschimbukistan stehender Rechner. Du müsstest also einerseits deinem PHP bekanntgeben, dass es ME(S)Z verwenden soll und nach jedem Verbindungsaufbau zum MySQL-Server ebenfalls die Verbindungs-Zeitzone auf deinen gewünschten Wert setzen. Damit klärst du das created-Problem, über das du noch gar nicht nachgedacht hast, zusammen mit dem modified-Problem, wenn du beides gleich behandelst.
Von diesem Standpunkt aus betrachtet: Ist es da nicht sinnvoller, bei _beiden_ Spalten den Typ 'datetime' zu nehmen, mit php eine gewünschte Zeitzone zu definieren und einen Timestamp zu erstellen und diesen dann an die DB weiterzugeben?
PHP verwendet den Unix-Timestamp. Das ist ein Wert, der die Sekunden seit 1.1.1970 auf UTC-Basis angibt. Das heißt, dass PHP von der aktuell eingestellten Zone nach UTC umrechnet und damit daselbe macht wie ein TIMESTAMP-Feld.
Das wäre zwar _etwas_ längerer Code aber unabhängig von Serverstandort/eingestellter Zeit am Server habe ich _immer_ die "richtige" Zeit, nämlich die anhand der von mir gewünschten Zeitzone.
Egal welchen Weg der beiden Wege du gehst, du hast immer eine standortunabhängige Zeit im Server. Mit dem Integer-Wert des Unix-Timestamps kann jedoch MySQL nichts anfangen, wenn du ihn nicht mit FROM_UNIXTIME() behandelst. Als Integer-Wert eignet er sich also nicht sehr gut, wenn du im DBMS damit Rechnungen und Recherchen anstellen willst.
dedlfix.