Wie am besten ein Datum und eine Uhrzeit in der DB speichern?

[AlexII]

Zitat von divBy0:

Aus der SQLite Dokumentation:

Zitat:

1.2 Date and Time Datatype

SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:

TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.

Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.

Das hat auch meine Frage ausgelöst. Aber weiter unten auf der Seite ist in der Tabelle DateTime vorhanden, SQLite akzeptiert das auch, also habe ich DateTime genommen.

[AlexII]

Zitat von Luckie:

Was spricht gegen eine Timestamp? Ganz ungünstig ist es als vorformatiertes Format abspeichern. dann musst du es jedes mal auseinander nehmen und wieder zusammensetzen, wenn es anders dargestellt werden soll. Fängt schon damit an, wenn du nur das Jahr brauchst. Für Timestamps gibt es fertige Funktionen bzw. man schreibt sie sich einmal und fertig. Die sonstigen Vorteile wurden ja schon genannt.

Hm... was genau ist hier ungünstig? Text oder DateTime?

[mkinzler]

Text!

[AlexII]

Zitat von mkinzler:

Text!

Ok, verstehe

[Bernhard Geyer]

Zitat von himitsu:

Warum als Text?
Und gut suchen? Nein!

* Man muß es erst konvertieren, dabei kann viel schief gehen (anderes Datumsformat und schon knallt es z.B. DE <> EN)
* es braucht mehr Platz
* man kann damit nicht rechnen (Datum + 4 Tage)
* es lässt sich blöde sortieren
* und filtern geht sowieso nicht (von-bis)
* wenn, dann dauert filtern/sortieren auch noch länger


Speicherst du Zahlen und vorallem Fließkommazahlen auch als Text?

Wenn man es nach ISO 8601 speichert gelten viel der Nachteile nicht.
Hier würde nur

* Platz
* Langsamer

übrig bleiben.
Alle anderen Punkte (Filtern/Teile/...) lässt sich prima mit dem ISO-Format machen.
Und wenn man x-DB-Systeme unterstützten will braucht man sich nicht mit den Unterschiedlichen Funktionen an dieser Stelle herumärgern.

Alle anderen (

[mkinzler]

Da er Text als flexibler gehalten hat, hat er wohl an kein standardisiertes Textformat gedacht.

[Bernhard Geyer]

Zitat von mkinzler:

Da er Text als flexibler gehalten hat, hat er wohl an kein standardisiertes Textformat gedacht.

Flexilber im Sinne von "Alle 2 Wochen Mittwoch um 12:00" wäre das ISO-Format schon.
Flexilber im Sinne von "Ich speicher jetzt nach US-Format" würde ich keinesfalls machen.

[jobo]

Zitat von Bernhard Geyer:

Flexilber im Sinne von "Alle 2 Wochen Mittwoch um 12:00" wäre das ISO-Format schon.
Flexilber im Sinne von "Ich speicher jetzt nach US-Format" würde ich keinesfalls machen.

Das ISO Format definiert auch Intervalle? Oder vielleicht doch nur maximal Zeitspannen?
Ich frag mich aber eher, ob es wirklich Sinn macht im Zusammenhang mit der Frage (..in der DB..) Text zu empfehlen.
Ich wollte nie Reports oder Abfragen dafür schreiben.

Im Rahmen einer DB-losen Webseite/Anwendung macht es vielleicht schon mehr Sinn. Aber da hab ich kaum Erfahrung.

[himitsu]

Kommt drauf an, welche ISO-Norm man hier anwendet.

[jobo]

Zitat von himitsu:

Kommt drauf an, welche ISO-Norm man hier anwendet.

Ich dachte wir hätten uns demokratisch auf 8601 geeinigt