nicht angemeldet
MySQL Datum-Funktionen
suithi,
bisher habe ich immer mit unix-ts gearbeitet und bin derzeit dabei, mit den Datum-Funktionen von mySQL zu spielen... vielleicht kann mir dieser oder jene das ein bischen schmackhafter machen: Habt Ihr Beispiele, wo die Vorteile des Feldtyps 'datetime' besonders schön zum Tragen kommen gegenüber einem unix-Timestamp als integer?
Bitte mal um Hinweise,
Hotti
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
-
Hi,
bisher habe ich immer mit unix-ts gearbeitet und bin derzeit dabei, mit den Datum-Funktionen von mySQL zu spielen... vielleicht kann mir dieser oder jene das ein bischen schmackhafter machen: Habt Ihr Beispiele, wo die Vorteile des Feldtyps 'datetime' besonders schön zum Tragen kommen gegenüber einem unix-Timestamp als integer?
Bei so gut wie allen Berechnungen, die man mit einem Datum anstellen will.
Bei Selektionen, die sich auf bestimmte Intervalle beziehen.
Bei Operationen, die auf bestimmte Datums-Bestandteile zugreifen, um bspw. danach zu selektieren/gruppieren.
etc. pp.MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Hi Chris,
[..] Habt Ihr Beispiele, wo die Vorteile des Feldtyps 'datetime' besonders schön zum Tragen kommen gegenüber einem unix-Timestamp als integer?
Bei so gut wie allen Berechnungen, die man mit einem Datum anstellen will.
Es sieht ganz danach aus ;)
Bei Selektionen, die sich auf bestimmte Intervalle beziehen.
Genau dazu hätte ich schon mindestens eine Anforderung...
Bei Operationen, die auf bestimmte Datums-Bestandteile zugreifen, um bspw. danach zu selektieren/gruppieren.
Da habe ich auch schon was geplant.
etc. pp.
Ok, alter table *G
Danke Dir,
weiter im Stoff,
Grüße an Alle,
Hotti
-
-
bisher habe ich immer mit unix-ts gearbeitet und bin derzeit dabei, mit den Datum-Funktionen von mySQL zu spielen... vielleicht kann mir dieser oder jene das ein bischen schmackhafter machen: Habt Ihr Beispiele, wo die Vorteile des Feldtyps 'datetime' besonders schön zum Tragen kommen gegenüber einem unix-Timestamp als integer?
time_t ist idR. auf 32 Bit signed beschränkt, in MySQL sind es 32 bit unsigend - das schränkt den Wertebereich in dem du produktiv arbeiten kannst auf etwa 68 Jahre ein (1970 bis 2038).
Sobald du z.B. mit Geburtsdaten hantierst oder Publikationen veröffentlichst, die vor der Unix-Epoche veröffentlicht wurden, brichst du dir mit time_t das Genick. Ebenso bei Astronomischen Ereignissen ist das unpraktisch - aber auch hier ist DATETIME oft ein Problem wenn sich der Datentyp nicht an ISO 8601 hält und das Jahr maximal 4-stellig speichert (siehe Year 10,000 problem). Ich weiß aber grade nicht. MySQL 5.1 unterstützt lt. Doku Wertbereiche zwischen '1000-01-01 00:00:00' und '9999-12-31 23:59:59' - wobei hier wohl eher mangelhaft übersetzt wurde und eigentlich "von" und "bis" gemeint ist.
-
Hi!
time_t ist idR. auf 32 Bit signed beschränkt, in MySQL sind es 32 bit unsigend - das schränkt den Wertebereich in dem du produktiv arbeiten kannst auf etwa 68 Jahre ein (1970 bis 2038).
Es ist irrelevant, wie MySQL über Timestamps denkt, wenn er nur einen Integer-Wert speichert.
Lo!
-
time_t ist idR. auf 32 Bit signed beschränkt, in MySQL sind es 32 bit unsigend - das schränkt den Wertebereich in dem du produktiv arbeiten kannst auf etwa 68 Jahre ein (1970 bis 2038).
Es ist irrelevant, wie MySQL über Timestamps denkt, wenn er nur einen Integer-Wert speichert.
Nein, es ist relevant wenn man den Datums- und Zeitfunktionen arbeiten will - die Spielerein die ChrisB angesprochen hat sind durchaus auch mit Timestamps möglich, man muss halt zuerst mit FROM_UNIXTIME() konvertieren und kann dann weiterarbeiten. Aufgrund des Verständnisses eines Timestamps ist der Effektive Wertebereich aber eben auf die Schnittmenge beider Interpretationen (signed und unsigned) begrenzt, das ergibt eine Spanne von (2^31)-1 - also Zeitpunkte vom 1. Jännner 1970 um 00:00:00 Uhr bis zum 19. Jänner 2038 um 03:14:08 Uhr.
-
Hi!
time_t ist idR. auf 32 Bit signed beschränkt, in MySQL sind es 32 bit unsigend - das schränkt den Wertebereich in dem du produktiv arbeiten kannst auf etwa 68 Jahre ein (1970 bis 2038).
Es ist irrelevant, wie MySQL über Timestamps denkt, wenn er nur einen Integer-Wert speichert.
Nein, es ist relevant wenn man den Datums- und Zeitfunktionen arbeiten will - die Spielerein die ChrisB angesprochen hat sind durchaus auch mit Timestamps möglich, man muss halt zuerst mit FROM_UNIXTIME() konvertieren und kann dann weiterarbeiten.Genau, erst wenn die Umrechnung ins Spiel kommt, wird es relevant. Aber wer will ständig umrechnen müssen? Dann lieber gleich ordentliche DATE(TIME)-Werte verwenden.
Egal was MySQL darüber denkt, ein Timestamp ist auch in anderen Systemen in der Regel kein geeigneter Typ für beliebige Zeitwerte. Ein Timestamp ist dafür gedacht, kostengünstig (4 Byte) eine aktuelle Zeit festzuhalten, und dafür ist der Zeitraum ab 1970 ausreichend, weil es davor keine Systeme gab, die dieses Format verwendeten. Dass er mit 4 Byte im Jahr 2038 aufhört, war der Kompromiss zu den damaligen Kosten für Speicher. Wer einen Timestamp für etwas anderes als das Festhalten der aktuellen Zeit verwendet, hat noch Verbesserungspotential (und sei es, dass er das System austauschen muss, das nur diesen Typ anbietet).
Lo!
-
-
-
hi,
[..] Wertbereiche zwischen '1000-01-01 00:00:00' und '9999-12-31 23:59:59' - wobei hier wohl eher mangelhaft übersetzt wurde und eigentlich "von" und "bis" gemeint ist.
Interessante Diskussion, danke!
Btw., mein Lieblingsthema:
mysql> select DATE_ADD('1582-10-04', INTERVAL 1 DAY);
+----------------------------------------+
| DATE_ADD('1582-10-04', INTERVAL 1 DAY) |
+----------------------------------------+
| 1582-10-05 |
+----------------------------------------+Naja, klar: MySQL verwendet den so genannten proleptischen gregorianischen Kalender (steht in der Doku). Kein Grund, sich daran aufzugeilen ;)
Aber hier:
mysql> select DATE_ADD('1500-02-28', INTERVAL 1 DAY);
+----------------------------------------+
| DATE_ADD('1500-02-28', INTERVAL 1 DAY) |
+----------------------------------------+
| 1500-03-01 |
+----------------------------------------+Muss ich mal nachfragen (denn es sollte der 29.2.1500 folgen): Ist das so, dass bei einem 'proleptischen gregorianischen' Kalender auch die Schaltjahresregelung des Gregorianischen Kalenders gilt?
Ansonsten:
mysql> select DATE_ADD('1582-10-15', INTERVAL 156454 DAY);
+---------------------------------------------+
| DATE_ADD('1582-10-15', INTERVAL 156454 DAY) |
+---------------------------------------------+
| 2011-02-22 |
+---------------------------------------------+rechnet MySQL hier richtig.
Hotti
-
Tach,
Muss ich mal nachfragen (denn es sollte der 29.2.1500 folgen):
nein, denn 1500 ist durch 100 und nicht durch 400 teilbar.
mfg
Woodfighter-
Moin,
Muss ich mal nachfragen (denn es sollte der 29.2.1500 folgen):
nein, denn 1500 ist durch 100 und nicht durch 400 teilbar.
Das wäre die Schaltjahr-Regelung des Gregorianischen Kalenders. Den gabs 1500 noch nicht.
mysql> select DATE_ADD('1001-01-01', INTERVAL 212486 DAY);
+----------------------------------------------+
| DATE_ADD('1001-01-01', INTERVAL 212486 DAY) |
+----------------------------------------------+
| 1582-10-08 |
+----------------------------------------------+Demzufolge verschiebt mySQL die Differenzen, rauskommen muss der 4.10.1582. Na gut, dann muss ich bis zur G. Reform so rechnen, wie bisher ;)
Hotti
-
Tach,
Das wäre die Schaltjahr-Regelung des Gregorianischen Kalenders. Den gabs 1500 noch nicht.
natürlich, und das weißt du auch: "Naja, klar: MySQL verwendet den so genannten proleptischen gregorianischen Kalender (steht in der Doku)."
mfg
Woodfighter
-
-
-
-
-
hi,
bisher habe ich immer mit unix-ts gearbeitet und bin derzeit dabei, mit den Datum-Funktionen von mySQL zu spielen... vielleicht kann mir dieser oder jene das ein bischen schmackhafter machen: Habt Ihr Beispiele, wo die Vorteile des Feldtyps 'datetime' besonders schön zum Tragen kommen gegenüber einem unix-Timestamp als integer?
Jetzt hab ich selbst einige Beispiele ;)
Gruppierung nach Tagen und bestimmte Tage in der where-Klause... echt schön!
Grüße an Alle,
Hotti