Also mir fallen auch ein paar Probleme ein, die man sich einhandelt, wenn man Datum in Datumsfeldern hält, anstelle von Textfeldern. Eines aus der Praxis:
Dokumente haben einen Gültigkeitsbereich. Datum gültig von und Datum gültig bis.
Anhand dieser Felder rechnet ein Agent nachts einen Status in die Dokumente, ob das Dokument abgelaufen, gültig oder zukünftig ist.
Da soll dann zum Beispiel eine Arbeitsanweisung zum 10.12.2011 in Kraft treten. Dummerweise hatte der Benutzer eine andere Zeitzone (vielleicht wohnt er wirklich dort, oder er hatte ein Sommerzeitproblem (schlechtes Beispiel im Dezember, aber sei's drum), oder was auch immer). Anstelle des Gültigkeitsbeginns 10.12.2011 00:00:00 bekommt das Dokument den Gültigkeitsbeginn 09.12.2011 23:00:00. Der täglich laufende Agent erkennt dann, dass das Dokument ab 09.12.2011 gültig sein soll, und setzt dadurch den Aktuell-Status einen Tag zu früh. Da kann man sich nicht gegen wehren. Oder mit welcher Toleranz soll man rechnen? Eine Stunde? Zwei? Das wird immer unsauber sein (ich habe eine Anwendung gesehen, in der ein (nicht dummer) Entwickler Datumswerte generell mit der Uhrzeit 03:00:00 ergänzt hat, damit Schwankungen durch Sommerzeitfehler sich nicht negativ auswirken. Damit ist aber der tiefere Sinn eines sauberen Datumsfeldes ad absurdum geführt).
Jahrelang habe ich genau mit diesem Problem gekämpft, das immer im Frühling auftrat, weil wieder irgendein Kunde die Sommerzeiteinstellung nicht korrekt vorgenommen hatte. Dieses Problem führte teilweise soweit, dass der gesamte produktive Betrieb still stand, da die Ablösung eines wichtigen Einstellungsdokuments so geschickt erfolgte, dass das alte Dokument gestern ungültig wurde, das neue aber erst morgen gültig. Da muss man dann in einem ansonsten revisionssicheren System mit irgendwelchen Agenten, Smarticons oder anderen Schweinereien an den Dokumenten hantieren, damit der Laden wieder in Gang kommt. Immer wieder gern genommen.
Als ich dann das zweite große System anfing, hatte ich mir geschworen, nie wieder Datumsfelder zu verwenden. Dieses neue große System läuft seit sechs Jahren ohne Probleme, setzt allerdings eine durchgängige deutsche Einstellung auf den Clients und den Servern voraus. Diesen Haken habe ich (auch Dank der Beiträge hier im Forum) erkannt. Aber wenn ich mal wieder ein neues großes System anfangen würde, würde ich wieder Textfelder nehmen, jedoch die Umwandlung von Beginn an in eigenen Routinen vornehmen.
Und seien wir doch ehrlich. Eine Umwandlung von Datumsfeldern in Text erfolgt doch ständig. Sei es bei einem Datenaustausch über ASCII-Im- und Exporte, über eine URL o.ä.
Natürlich muss man, wie immer, die Rahmenbedingungen abstecken. Nutze ich ein Datum, um internationale Zusammenarbeit zu organisieren, brauche ich natürlich echte Datumsfelder mit Zeitzone, sonst ist das Chaos perfekt. Eher formalistische Anwendungen, die sich mit Arbeitsanweisungen, Revision, Prüfungen und solchen Dingen befassen, brauchen sie eher nicht.
Abhängig von dem Umfeld, in dem man sich bewegt, sind da natürlich die Befindlichkeiten unterscheidlich. Ein striktes Nein oder Ja kann es m.E. daher auch hier nicht geben. Und nicht alles, was falsch erscheint, ist auch wirklich falsch.
