Verschiedene Inhalte in DB speichern-beste Lösung?

[Html]

Hallo bin gerade dabei ein kleines CMS für unsere FeuerwehrHomepage zu schreiben. Unteranderem sollen neue Einsätze über ein Formular in die Datenbank eingetragen werden können. Da dieses mein erstes Projekt mit php ist fehlt mir noch etwas die routine.

Daher meine Frage: Wie speichere ich am besten das Datum und die Alarmierungszeit/Einsatzende.

Ist es am besten wenn ich das Datum und die Uhrzeit in einen timestamp wandle, oder etwa Datum und Uhrzeit getrennt. Uhrzeit mit Doppelpunkt in DB speichern?

Wie würdet ihr es machen? Was ist die beste Lösung?


Anbei noch ein Bild vom jetzigen Formular.

mfg,Olli

 

[Flex]

Ich arbeite bevorzugt mit einem Feld Integer 10 und speichere den Unix Timestamp.

 

[26toto26]

Ich persönlich finde den Unix Timestamp besser. Es lassen sich damit später bessere Auswertungen berechnen.

Finde ich.... aber ich muss dazu sagen das ich auch noch totaler neuling bin.

Gruß
Toto

 

[Html]

Hallo habe so eben gelesen, dass mysql ja folgende Feldtypen schon anbietet:

DATE Datum-Feld. Erlaubter Bereich von 1000-01-01 bis 9999-12-31.


DATETIME Kombinationsfeld aus Datum und Zeit. Erlaubter Bereich von 1000-01-01 00:00:00 bis 9999-12-31 23:59:59.


TIMESTAMP Zeitstempel-Feld. Nicht zu verwechseln mit dem UNIX-Timestamp.
Der Eintrag wird bei vorhandenem TIMESTAMP-Feld automatisch
gesetzt und eignet sich insbesondere zum Festhalten von Zeiten bei
UPDATE- und INSERT-Operationen. Erlaubter Bereich von 1970-01-
01 00:00:00 bis zum Ende des Jahres 2037.


TIME Zeit-Feld. Erlaubter Bereich von -838:59:59 bis 838:59:59.



Nun bin ich etwas verwirrt. Ist es dann nicht sinnvoller diese Typen zu nutzen als alles in den unixtimestamp zu wandeln. Zudem ist dieser ja bis 2037 beschränkt.

?


Mfg,Olli

 

[mAu]

Ja, im Prinzip schon; aber die meisten bevorzugen den UNIX-Timestamp, weil die Datumsfunktionen in PHP ja standartgemäß damit rechnen.

 

[Dennis Wronka]

Ausserdem wird sich jemand sicher dem Problem mit dem Ueberlauf der Unixzeit vor dem entsprechenden Zeitpunkt widmen.

Und ich bin auch grad nicht sicher, aber ich meine mich zu erinnerern, dass dieses Problem auf 64-Bit-Systemen nicht besteht. Aber wie gesagt, ich bin nicht ganz sicher, meine aber mal was dazu gelesen zu haben.

Ah, fix nachgeschaut und ich erinnerte mich richtig:

Being 32 bits (of which one bit is the sign bit) means that it covers a range of about 136 years in total. The minimum representable time is 1901-12-13T20:45:52Z, and the maximum representable time is 2038-01-19T03:14:07Z. At 2038-01-19T03:14:08Z this representation will overflow. This milestone is anticipated with a mixture of amusement and dread; see the separate section below.

In some newer operating systems, time_t has been widened to 64 bits. In the negative direction, this goes back more than twenty times the age of the universe, and so suffices. In the positive direction, whether the approximately 293 billion representable years is truly sufficient depends on the ultimate fate of the universe, but it is certainly adequate for most practical purposes.

 

[Mairhofer]

Sicher ist die Verwendung von Unix-Timestamps die einfachste Methode, jedoch würde ich die unterstützen Typen von MySQL verwenden.
Das hier angesprochene Problem, das man nach dem Auslesen sofort mit dem Unix Timestamp arbeiten kann, lässt sich in der SQL Anweisung leicht umgehen.

Beispiel:
- datums_feld ist die Spalte in der DB, welche als Typ Date oder Datetime haben
- sql_tabelle ist die Tabelle in der Datenbank

SELECT UNIX_TIMESTAMP(datums_feld) AS datum_als_unixtimestamp FROM sql_tabelle;

 

[Gumbo]

Der Unix-Zeitstempel beschreibt einen sekundengenauen Zeitpunkt und nicht eine Zeitspanne, was ein Tag mit seinen 86400 Sekunden ja für gewöhnlich ist. Und genau deswegen ist ein Unix-Zeitstempel dafür nicht geeignet.