core
core copied to clipboard
MetaModels
FR: Date und Date-Time als entsprechende Werte in DB und nicht als Timestamp
Ich plädiere dafür die Attribute Datum (Date) und Datum+Zeit (Datetime) als solche auch in der Datenbank abzulegen und nicht als Unix-Timestamp - für den Timestamp kann es einen eigenes Attribut geben.
Hintergrund ist die m.E. "falsche" Abspeicherung von Werten. Das Datum ist "die Benennung eines Tages im jeweiligen Kalenderjahr im Rahmen eines Kalenders" https://de.wikipedia.org/wiki/Kalenderdatum und keine Angabe in Sekunden.
Als Analogie: will ich Längen explizit in Metern abspeichern - also 1m, 2m. 3m usw. - würde sicher kaum jemand auf die Idee kommen, "2m" als "2340mm" oder "2180mm" abzuspeichern.
Aktuell wird beim Speichern des Datums 30.08.2015 z.B. der Timestamp "1440955448" abgespeichert - der beinhaltet aber eigentlich "2015-08-30 19:24:08".
Diese "übergenaue" Abspeicherung von Werten birgt die Gefahr, dass Vergleiche nicht korrekt funktionieren. Wenn z.B. der Vergleich zu einem Datum >= 30.08.2015 durchgeführt wird und dabei das Datum zu einem Timestamp umgerechnet, schlägt der "= Vergleich" bis 19:24:08 fehl.
Also: ein Datum ist ein Datum ist ein Datum ;-)
Datum+Zeit: dito
Wenn du das willst, dann kannst du immer noch das normale Textattribute nehmen und die Eingabe per dcaconfig.php anpassen. Von daher sehe ich da keinen Sinn drinn das allgemein zu ändern.
Viele Grüße
Das wäre ggf. machbar - da es für die Werte bzw. Datentypen zugehörige Entsprechungen in MySQL (und anderen DB-Systemen) gibt, halte ich es für angebracht auch diese zu verwenden.
Du solltest nicht "2m" oder "2,15m" oder "2.15m" in der Datenbank speichern, sondern "2150" oder "2.15". Alles andere führt früher oder später zu Problemen. Auch in einem Tabellenprogramm solltest du in ein Feld nicht z.B. "2m" eintragen, sondern "2" und das Feld dann formatieren nach z.B. "2,00 m".
Ein Timestamp ist ein Zeitpunkt, ein Datum (Kalendertag) ist ein Zeitraum. Deswegen ist es in Ordnung, dass eine Zeit mitgespeichert wird. Du speicherst ja nur einen Wert. Am Ende greifst du halt nur Tag, Monat und Jahr ab. Wenn du beim Speichern unerschiedliche Uhrzeiten bekommst und das nicht möchtest, kannst du beim Speichern die Uhrzeit z.b. auf 00:00 setzen. Oder du machst deine Vergleiche nachher mit PHP nachdem du die Zeit auf 0 gesetzt hast oder nur Tag, Monat und Jahr abgegriffen hast.
Dieser Vergleich ist auf jeden Fall zuverlässig, wohingegen du bei Datumsvergleichen auf Stringebene Probleme bekommen wirst. Z.B. wird ein BE oder FE in EN ein Datum anders anzeigen als eines in DE. Nachher hast du dann z.B. solche Strings in dem Feld "30.08.2015, 08.30.15 usw.
Also die richtige Art ein Datum zu speichern ist auf jeden Fall als Timestamp. Wie MacKP schon sagte: Nimm ein Textfeld, wenn du einen String möchtest.
Ich finde, was fehlt ist ein vernünftiger Filter für dieses Attribut. Einer, der es auch ermöglicht die Uhrzeit nicht zu berücksichtigen - oder eine Abfrage nach Jahr, Monat, Kalenderwoche oder Wochentag zu machen. Der Unix-Timestamp ist da wohl eher nicht das wirkliche Problem (obwohl der eingeschränkte Wertebereich auch in contao/core auch immermal wieder zu Diskussionen führt).
Hallo Aybee,
zu meiner "Analogie": dass ich die Einheit nicht mitspeichern würde ist schon klar - mir ging es darum, dass man statt 2 (gleich Datum) ein 2150 (Timestamp) speichert und davon ausgeht, dass es eine "Zwei" ist.
Wie Du schon richtig bemerkt hast, sind Timestamp und Date zwei unterschiedliche Dinge und sollten m.E. auch so behandelt werden. Schließlich gibtz es entsprechende Datentypen in MySQL, ansonsten könnte man (fast) alle Werte in eine Textfeld werfen...
nächstes Problem sehe ich bei der Option "eindeutige Werte" - aktuell ist für ein Datum bzw. Datum+Zeit (auf Minutenbasis) nicht festgelegt, "welcher Timestamp" verwendet wird...
Beispiel: speicher man das Datum 28.01.2016 ab, wird als TS "1453964929" abgespeichert - in einem zweiten Datensatz für das selbe Datum der Wert "1453964966".
Bei einem Vergleich per "isUnique" wird ein "false" geliefert - was in dem Fall falsch ist :-(