✔ Richtige Ausgabe für MySQL DateTime Datentyp

[DataFox]

Hi

Ich kriegs irgendwie nicht gebacken: Habe eine MySQL-Tabelle mit einem Feld dessen Datentyp DATETIME ist. Sieht so aus: 0000-00-00 00:00:00

Nun will ich mit PHP ganz easy einen INSERT-Query ausführen wobei dieses DATETIME-Feld das sich "zeit" nennt entsprechend gesetzt werden soll. Ich habe keine Funktion gefunden die direkt kompatibel mit diesem MySQL DATETIME Datentyp ist.

Muss man sich wirklich mühsam die Uhrzeit nach diesem Muster zurecht schnippern, oder gibt es da doch noch eine einfache Funktion für?

Gruß
Laura

 

[splasch]

Nein es gibt einen Sql befehl der lautet NOW()

Also einfach bei deinen insert das Now() eintragen schon hast das aktuelle datum und zeit drin.


Mfg Splasch

 

[l0c4lh05t]

Das hier kannst du dir ja auch noch einmal anschauen

sich wirklich mühsam die Uhrzeit nach

Kann mir mühsamere Aufgaben vorstellen

date("Y-m-d H:i:s", time());

Was auch immer, wieso verwendest du DATETIME? Oder besser formuliert: Warum nicht einen 10 stelligen Integer (für ein Unix Timestamp)? Dann kann man die Zeit immer so ausgeben, wie man es gerade für ästhetisch hält.

...nettes Avatar

 

[splasch]

Was auch immer, wieso verwendest du DATETIME? Oder besser formuliert: Warum nicht einen 10 stelligen Integer (für ein Unix Timestamp)? Dann kann man die Zeit immer so ausgeben, wie man es gerade für ästhetisch hält.

Ich finde Datetime auch besser und dort kann mans auch immer so ausgeben wie mans möchte. Das umdrehen der Positionen ist ein klax.

Timestamp deswegen nicht weil es ersten eine beschränkte laufzeit hat.Auch wenn es noch viele Jahre sind aber dann wird dein Script nicht mehr funktionieren weil der Timestamp steht.

Übrings wenn man mit Datetime rechnen will dann kann man das genau so einfach umformen als were es eine Timestamp zahl.

Mfg Splasch

 

[l0c4lh05t]

Ich finde Datetime auch besser und dort kann mans auch immer so ausgeben wie mans möchte. Das umdrehen der Positionen ist ein klax.

+

Übrings wenn man mit Datetime rechnen will dann kann man das genau so einfach umformen als were es eine Timestamp zahl.

Das ist etwas für die Schwachsinnigen. Warum nicht dann nicht direkt Timestamp?

Auch wenn es noch viele Jahre sind aber dann wird dein Script nicht mehr funktionieren weil der Timestamp steht.

317 Jahre sind es insgesamt, falls ich mich nicht verrechnet habe (60*60*24*365=31536000, 9999999999/31536000=317), dann sollte eine 11 Stelle hinzukommen. Wenn es soweit ist können deine Urahnen die MySQL Tabelle ja entsprechend erweitern.

Irgendwie finde ich keine guten Argumente für DATETIME, also werde ich weiterhin Timestamps benutzen.

 

[splasch]

@l0c4lh05t

Da bist du aber schlecht informiert! Solltes dich mal voher erkundigen bevor du wahl lose berechnung vorgibst.

http://de.wikipedia.org/wiki/Timestamp
http://de.wikipedia.org/wiki/Jahr-2038-Problem

Timestamp startete am 1. Januar 1970 00:00 und wird mit größter warscheinlich am Am 19. Januar 2038 um 03:14:08 Probleme bekommen weil dann die 32-Bit-Zahl am ende ist.

Mfg Splasch

 

[Robby12]

@l0c4lh05t

Da bist du aber schlecht informiert! Solltes dich mal voher erkundigen bevor du wahl lose berechnung vorgibst.

http://de.wikipedia.org/wiki/Timestamp
http://de.wikipedia.org/wiki/Jahr-2038-Problem

Timestamp startete am 1. Januar 1970 00:00 und wird mit größter warscheinlich am Am 19. Januar 2038 um 03:14:08 Probleme bekommen weil dann die 32-Bit-Zahl am ende ist.

Mfg Splasch

Schitt, da bin ich über 80 Jahre alt. Muss langsam bis da hin meine SQL fertig bekommen.

 

[saftmeister]

Bis 2038 (immerhin noch ca. 24 Jahre!) werden die Experten, die RDBMS und Betriebssysteme entwickeln, sicher auf 64Bit umgestellt haben. Dann sind es wieder ein paar Jährchen mehr. Das einzige, was das noch verhindern kann, sind die Embedded Systeme, die dann immer noch mit 32Bit arbeiten (müssen). Ein Timestamp hat außerdem noch den Vorteil, mit ihm kann man elegant rechnen. Ich kann es nicht beschwören, da ich den Quellcode von MySQL noch nicht so genau betrachtet habe, aber wenn man mit einem DATETIME rechnen o. vergleichen will, wird der intern sicher auch erstmal in einem Timestamp umgerechnet. Folglich ist DATETIME auch von Zeitstempeln abhängig.

 

[mermshaus]

Also, DATETIME ist zumindest absolut legitim. Siehe etwa „mysql datetime vs timestamp“.

Zum Beispiel:

- http://stackoverflow.com/questions/409286/datetime-vs-timestamp

„Wenn ich das Ende irgendeiner Zeitspanne speichern will, kann das Datum mitunter weit in der Zukunft liegen“ ist zum Beispiel – auch abgesehen etwa von speziellen MySQL-Funktionen für DATETIME-Werte – ein ganz gutes Argument.

Ich würde alle Daten in UTC speichern und bei Ausgabe entsprechend in die gewünsche Besucher-Zeitzone umrechnen. Das wäre dann statt NOW etwa UTC_TIMESTAMP.

- https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_utc-timestamp

Timestamps sind vielleicht eher für so Dinge wie „Zeitpunkt des Anlegens“, „Zeitpunkt der letzten Änderung“ eines Datensatzes nützlich.

 

[saftmeister]

OK, klingt plausibel. Ich möchte noch einen weiteren Grund einbringen, der für Zeitstempel spricht: Migration zu einem anderen RDBMS. Was macht man mit den Daten, wenn man mal auf ein anderes System umstellen will? Einen mehrstelligen Integer-Wert kann jedes RDBMS (BIGINT, etc) speichern. Einen Konvertierungsalgo muss man sich evtl. erstmal selbst schreiben.