Das tolle an "Standards" ist, dass es so viele davon gibt
So zum Beispiel, was die Formatierung von Datums- und Zeitangaben angeht.
In Java's DateFormat wird für das spezifizieren eines Zeitoffset der RFC 822 unterstützt, wo man einfach mit dem Zeichen "z" diesen Offset im Format "+HHmm" parsen kann.
Hätte man also einen Datums-String, der folgendermaßen aussieht:
kann man das mit zB SimpleDateFormat mit folgendem Format-String parsen:
Soweit, so schön. Problematisch wird es allerdings, wenn man solche Angaben in XML-Dokumenten haben möchte.
Die XSD-Spezifikation stellt einen Typ "xs:dateTime" bereit, der einen String erwartet, der dem oben angegebenen "ähnlich" sieht. ähnlich, weil ein kleines Detail eben doch anders sein muss: im Offset, müssen Stunden und Minuten durch einen Doppelpunkt getrennt werden! Damit würde der String also so aussehen:
...und der SimpleDateFormater würde das nicht als valide Datumsangabe ansehen, gemäß dem oben stehenden FormatString! Denn der RFC 822 sieht an dieser Stelle keinen Doppelpunkt vor. An den hält sich XSD auch gar nicht, sondern an RFC 3339 (und auch das nur partiell - RFC 3339 erlaubt einige Dinge, die xs:dateTime nicht akzeptiert. zB ein Leerzeichen statt dem "T" in der Mitte zu benutzen).
Der geneigte Entwickler möchte vermutlich bereits an dieser Stelle den Kopf auf die Tischplatte knallen. Nun das war zumindest meine erste Reaktion. Die Zweite war: "da gibts doch bestimmt was von Ratiopharm... äh, ich meine Apache (Commons)." Die haben ja sonst auch für alle gängigen Probleme "schon mal etwas vorbereitet". Bei der Suche stieß ich dann darauf, dass es sogar schon etwas in Java eingebautes gibt!
Man soll es nicht für möglich halten: "javax.xml.bind.DatatypeConverter" stellt eine Methode "parseDateTime" bereit, die einen "lexicalXSDDateTime"-String erwartet. ...natürlich, da hätte man ja drauf kommen können, dass eine Datumsangabe ein Datentyp ist
In Java's DateFormat wird für das spezifizieren eines Zeitoffset der RFC 822 unterstützt, wo man einfach mit dem Zeichen "z" diesen Offset im Format "+HHmm" parsen kann.
Hätte man also einen Datums-String, der folgendermaßen aussieht:
2011-03-23T22:15:00.000+0100
kann man das mit zB SimpleDateFormat mit folgendem Format-String parsen:
yyyy-MM-dd'T'HH:mm:ss.SSSz
Soweit, so schön. Problematisch wird es allerdings, wenn man solche Angaben in XML-Dokumenten haben möchte.
Die XSD-Spezifikation stellt einen Typ "xs:dateTime" bereit, der einen String erwartet, der dem oben angegebenen "ähnlich" sieht. ähnlich, weil ein kleines Detail eben doch anders sein muss: im Offset, müssen Stunden und Minuten durch einen Doppelpunkt getrennt werden! Damit würde der String also so aussehen:
2011-03-23T22:15:00.000+01:00
...und der SimpleDateFormater würde das nicht als valide Datumsangabe ansehen, gemäß dem oben stehenden FormatString! Denn der RFC 822 sieht an dieser Stelle keinen Doppelpunkt vor. An den hält sich XSD auch gar nicht, sondern an RFC 3339 (und auch das nur partiell - RFC 3339 erlaubt einige Dinge, die xs:dateTime nicht akzeptiert. zB ein Leerzeichen statt dem "T" in der Mitte zu benutzen).
Der geneigte Entwickler möchte vermutlich bereits an dieser Stelle den Kopf auf die Tischplatte knallen. Nun das war zumindest meine erste Reaktion. Die Zweite war: "da gibts doch bestimmt was von Ratiopharm... äh, ich meine Apache (Commons)." Die haben ja sonst auch für alle gängigen Probleme "schon mal etwas vorbereitet". Bei der Suche stieß ich dann darauf, dass es sogar schon etwas in Java eingebautes gibt!
Man soll es nicht für möglich halten: "javax.xml.bind.DatatypeConverter" stellt eine Methode "parseDateTime" bereit, die einen "lexicalXSDDateTime"-String erwartet. ...natürlich, da hätte man ja drauf kommen können, dass eine Datumsangabe ein Datentyp ist