Mailinglisten-Archive |
Hi Michael, Michael Raab schrieb: > ist oder nicht. Das Datum wird in dem Obengenannten Format in die > Datenbank abgelegt. Den Ablauf zu programmieren ist nicht das Problem. > Ich sehe das Problem in der SQL-Abfrage. Denn wenn das Datum im Format > tt.mm.jjjj gespeichert wird, kann man da einfach mittels "where > ablaufdatum>'25.12.2002'" abfragen oder könnte es da zu unerwünschten > Überraschungen kommen ? Du benutzt als Datumsformat einen String. Die Stringordnung sortiert mit von links nach rechts wandernder Priorität über die Ordinalität des aktuellen Chars, bei MySQL z.B. iirc in schwedischer Telefonbuch-Reihenfolge, also mit auf Z folgende Umlaute. Diese Sortierung ist auch massgeblich für < bzw. >-Vergleiche. Damit ist der 26.01.2002 größer als der 25.12.2007. Also braucht man ein Datumsformat, dass eine Sortierordnung hat, dass die Datums- abfolge berücksichtigt, also ein TimeStamp-Format. Der Unix-Timestand zählt die Sekunden seit dem 1.1.1970 und sortiert mit diesen numerisch. Damit läßt sich jede sekundengenaue Zeit abbilden, es wird wenig Speicherplatz verbraucht, und dass Format ist für Menschen mit normaler mathematischer Begabung unlesbar. Einige Datumsformate, wie etwa bei MySQL, speichern Daten als String, der auch nach normaler Stringordnung sortiert werden kann. Datetime ist z.B. YYYY-MM-DD HH:MM:SS . Damit dein Datum mit anderen Daten korrekt verglichen werden kann, sollte es also in einem Format vorliegen, dass eine Sortierung a la Timestamp erlaubt. Afaik kann man mit den Bordmitteln von MySQL nur mit sehr viel Mühe Strings zu Datumsen umbauen, weil so etwas wie mktime fehlt (statt dessen müßte man eine Horde von substr usw. nutzen, um damit z.B. einen Unix-Timestand zu bauen.) Mit PHP geht es erheblich einfacher - weil hier gibts ja mktime. Meine Empfehlung ist also : das Datumsformat, wenn man keine Daten vor dem 1.1.1970 braucht, auf Unix-Timestamp umstellen und damit weiterarbeiten. Liebe Grüße - johann
php::bar PHP Wiki - Listenarchive