Datums- und Zeit-Datentypen

(Auszug aus "XML Schema" von Eric van der Vlist)

Die auf dieser Seite besprochenen Datentypen werden in der folgenden Abbildung dargestellt.

Datums- und Zeit-Datentypen

Abbildung: Datums- und Zeit-Datentypen

Das Reich von ISO 8601

Die W3C-Empfehlung »XML Schema Teil 2: Datentypen« bestätigt erneut, wie schwierig es ist, Zeiten genau anzugeben.

Die Unterstützung für Datums- und Zeit-Datentypen beruht vollständig auf einer Untermenge des Standards ISO 8601, der damit das einzige von W3C XML Schema unterstützte Format darstellt. Der Zweck von ISO 8601 besteht darin, die Gefahr des Durcheinanders zwischen den unterschiedlichen Datums- und Zeitformaten, die in den verschiedenen Ländern verwendet werden, zu bannen. Anders ausgedrückt, unterstützt W3C XML Schema diese regionalen Datums- und Zeitformate nicht, sondern erzwingt die Verwendung von ISO 8601 für jeden Datentyp, der die Semantik von Datums- oder Zeitangaben hat. Während das für Austauschformate sehr vorteilhaft ist, ist es fragwürdig, wenn XML dazu benutzt wird, Benutzerschnittstellen zu definieren, denn ISO 8601 ist nicht sehr benutzerfreundlich, wie wir noch sehen werden. Die Variationen bei der Verwendung des Monatsnamens oder unterschiedliche Reihenfolgen der Werte von Jahr, Monat und Tag sind nicht die einzigen Opfer dieser Entscheidung: ISO 8601 erzwingt die Verwendung des gregorianischen (christlichen) Kalenders zu Lasten von Kalendern, die von anderen Kulturen oder Religionen verwendet werden.

ISO 8601 beschreibt mehrere Formate, um Datumsangaben, Zeiten, Zeiträume und sich wiederholende Zeitpunkte mit unterschiedlichen Ebenen von Genauigkeit und Unbestimmtheit zu beschreiben. Nach vielen Diskussionen hat W3C XML Schema eine Untermenge dieser Formate ausgewählt und je einen primitiven Datentyp für jedes der unterstützten Formate geschaffen.

Die Unbestimmtheit, die bei einigen dieser Formate gestattet ist, macht vieles schwerer, insbesondere wenn Vergleiche oder Berechnungen betroffen sind. Beispielsweise ist es möglich, einen Zeitpunkt zu definieren, ohne die Zeitzone anzugeben, die dann als unbestimmt betrachtet wird. Diese unbestimmte Zeitzone ist innerhalb des ganzen Dokuments identisch (und auch innerhalb des Schemas und aller dazu passenden Instanzdokumente), daher ist es kein Problem, zwei Zeitpunkte ohne Zeitzone zu vergleichen. Das Problem entsteht, wenn man zwei Zeitpunkte vergleichen muss, von denen einer eine Zeitzonenangabe enthält, der andere hingegen nicht. Das Ergebnis dieses Vergleichs wird unbestimmt sein, wenn die beiden Werte zu nahe beieinanderliegen, denn der eine von beiden kann zwischen –13 und +12 Stunden von der »Weltzeit« (Coordinated Universal Time, UTC) abweichen. Die Unterstützung für diese Zeitpunkt-Datentypen führt also zum Begriff einer »Teilordnungsrelation«.

Eine weitere Warnung bezüglich ISO 8601 wird dadurch erforderlich, daß Zeitzonen nur in Form einer zeitlichen Abweichung von UTC unterstützt werden, wobei der Begriff der Sommerzeit unter den Tisch fällt. Wenn beispielsweise eine Anwendung, die in mitteleuropäischer Sommerzeit (MESZ) läuft, die Zeitzone angeben möchte – und wir haben gesehen, daß dies notwendig ist, um Zeitpunkte miteinander vergleichen zu können –, muß die Anwendung wissen, ob ein Datum im Sommer (dann liegt die Zeitzone zwei Stunden nach UTC) oder im Winter (dann liegt die Zeitzone nur eine Stunde nach UTC) liegt. ISO 8601 ignoriert die »benannten Zeitzonen«, die zur Sommerzeit gehören (wie etwa PST, BST oder WET) und die wir im Alltagsleben benutzen. Die Zeitzone zu ignorieren kann als etwas gefährliche Abkürzung verstanden werden, um anzugeben, daß ein Zeitpunkt sich nach der »lokalen Zeit« richtet, wie immer die aussehen mag.

Datentypen

Zeitpunkt: xs:dateTime

Der Datentyp xs:dateTime definiert einen »bestimmten Punkt in der Zeit«. Dies ist eine Untermenge dessen, was ISO 8601 einen »Moment in der Zeit« nennt. Sein lexikalischer Wert folgt dem Format »CCYY-MM-DDThh:mm:ss« (C: Jahrhundert, YY: Jahr (zweistellig) usw.), wobei alle Felder vorhanden sein müssen und wahlweise durch ein Vorzeichen und einleitende Ziffern begonnen werden können, sofern nötig. Am Ende können Dezimalstellen für Bruchteile einer Sekunde stehen, dahinter kann die Zeitzone stehen. Die Zeitzone kann als Wert den Buchstaben »Z«, der für UTC steht, oder die Zeitdifferenz gegenüber UTC haben.

Als Werteraum von xs:dateTime wird der Zeitpunkt selbst angesehen. Die Zeitzone, die (sofern vorhanden) den Wert definiert, wird als bedeutungslos angesehen, was ein Problem für einige Anwendungen erzeugt. Selbst wenn sich nämlich 2002-01-18T12:00:00+00:00 und 2002-01-18T11:00:00-01:00 auf denselben »Moment in der Zeit« beziehen, tragen sie doch unterschiedliche Zeitzonenangaben, und dies sollte sich im Werteraum widerspiegeln.

Gültige Werte für xs:dateTime sind beispielsweise:

2001-10-26T21:32:52
2001-10-26T21:32:52+02:00
2001-10-26T19:32:52Z
2001-10-26T19:32:52+00:00
-2001-10-26T21:32:52
2001-10-26T21:32:52.12679

Die folgenden Werte sind ungültig

2001-10-26 (alle Teile müssen angegeben werden)
2001-10-26T21:32 (alle Teile müssen angegeben werden)
2001-10-26T25:32:52+02:00 (die Stundenangabe »25« ist außerhalb des zulässigen Bereichs)
01-10-26T21:32 (alle Teile müssen angegeben werden)

Von den oben angegebenen Beispielen haben drei identische Werte im Werteraum:

2001-10-26T21:32:52+02:00
2001-10-26T19:32:52Z
2001-10-26T19:32:52+00:00

Der erste der Werte (2001-10-26T21:32:52), der keine Zeitzonenangabe enthält, wird als unbestimmter Wert zwischen 2001-10-26T21:32:52-14:00 und 2001-10-26T21:32:52+14:00 angesehen. Berücksichtigt man auch die Sommerzeit, können nationale Regelungen diesen Bereich verändern. Der Bereich lag zum Zeitpunkt der Veröffentlichung der Empfehlung zwischen -13:00 und +12:00, die W3C-Arbeitsgruppe hat jedoch großzügig kalkuliert, um mögliche Änderungen der Regelungen unterbringen zu können.

Unabhängig von der Unbestimmtheit der Zeitzone, falls keine angegeben ist, legt die W3C XML Schema Recommendation fest, daß sich die Werte von Zeitpunkten ohne Zeitzone implizit auf dieselbe unbestimmte Zeitzone beziehen. Daher können sie untereinander verglichen werden. Während dies für lokal laufende Anwendungen, die nur innerhalb einer einzigen Zeitzone eingesetzt werden, gut ist, stellt es eine Quelle möglicher Verwirrung und auch Fehler dar, wenn es sich um weltweite Anwendungen oder gar um Anwendungen handelt, die die Länge eines Zeitraums zwischen zwei Zeitpunkten berechnen, die zu verschiedenen Sommerzeitphasen innerhalb derselben Zeitzone gehören.

Zeiträume: xs:date, xs:gYearMonth und xs:gYear

Der lexikalische Raum des Datentyps xs:date ist identisch mit dem Datumsteil von xs:dateTime. Genau wie xs:dateTime enthält er eine Zeitzone, die immer angegeben werden sollte, damit zwei Datumsangaben stets ohne Mehrdeutigkeit miteinander verglichen werden können. Laut Definition durch W3C XML Schema ist ein Datum ein Tag seiner Zeitzone, »unabhängig davon, wie viele Stunden dieser Tag hat«. Aus dieser Definition folgt, daß zwei Datumsangaben, die in unterschiedlichen Zeitzonen definiert sind, einander nicht gleich sein können, außer wenn sie dasselbe Zeitintervall bezeichnen (zum Beispiel 2001-10-26+12:00 und 2001-10-25-12:00). Eine andere Konsequenz besteht darin, daß die Ordnungsrelation zwischen einem Datum mit und einem ohne Zeitzone genau wie bei xs:dateTime eine Teilordnung ist.

Gültige Werte für xs:date sind beispielsweise:

2001-10-26
2001-10-26+02:00
2001-10-26Z
2001-10-26+00:00
-2001-10-26
-20000-04-01

Die folgenden Werte sind ungültig:

2001-10 (alle Teile müssen angegeben werden)
2001-10-32 (der Tagesteil (32) ist außerhalb des zulässigen Bereichs)
2001-13-26+02:00 (der Monatsteil (13) ist außerhalb des zulässigen Bereichs)
01-10-26 (der Jahrhundertteil fehlt)

xs:date stellt einen Tag dar, der durch ein Datum des gregorianischen Kalenders identifiziert wird (und deshalb auch »gYearMonthDay« hätte genannt werden können). xs:gYearMonth (»g« für »gregorianisch«) ist ein Monat des gregorianischen Kalenders, xs:gYear ist ein Jahr dieses Kalenders. Diese drei Datentypen sind festgelegte Zeiträume, und bei jedem kann wahlweise eine Zeitzone angegeben werden. Die einzigen Unterschiede sind tatsächlich ihre Länge (ein Tag, ein Monat bzw. ein Jahr) und ihr Format (d.h. ihre lexikalischen Räume).

Das Format von xs:gYearMonth ist genau dasjenige von xs:date, jedoch ohne den Tagesteil. Gültige Werte für xs:gYearMonth sind unter anderem:

2001-10
2001-10+02:00
2001-10Z
2001-10+00:00
-2001-10
-20000-04

Die folgenden Werte sind ungültig:

2001 (der Monatsteil fehlt)
2001-13 (der Monatsteil ist außerhalb des zulässigen Bereichs)
2001-13-26+02:00 (der Monatsteil ist außerhalb des zulässigen Bereichs)
01-10 (der Jahrhundertteil fehlt)

Das Format von xs:gYear ist genau dasjenige von xs:gYearMonth, jedoch ohne den Monatsteil. Gültige Werte für xs:gYear sind unter anderem:

2001
2001+02:00
2001Z
2001+00:00
-2001
-20000

Die folgenden Werte sind ungültig:

01 (der Jahrhundertteil fehlt)
2001-13 (es darf kein Monatsteil angegeben werden)

Diese Unterstützung für Zeiträume ist sehr restriktiv. Die Zeiträume können nur volle Tage, Monate oder Jahre des gregorianischen Kalenders umfassen, sie können keine beliebigen Längen oder Anfangszeiten haben.

Wiederkehrende Zeitpunkte: xs:time

Der lexikalische Raum von xs:time ist identisch mit dem Uhrzeitteil von xs:dateTime. Die Semantik von xs:time stellt einen Zeitpunkt dar, der sich jeden Tag wiederholt; 01:20:15 bedeutet »der Zeitpunkt, der jeden Tag um 01:20:15 wiederkehrt«. Genau wie xs:date und xs:dateTime akzeptiert xs:time wahlweise eine Zeitzonendefinition. Das Problem des Vergleichs von Zeiten mit und ohne Zeitzonenangabe tritt auch hier auf.

Entgegen der Tatsache, daß 01:20:15 gewöhnlich dazu verwendet wird, eine Zeitdauer von 1 Stunde, 20 Minuten und 15 Sekunden anzugeben, ist für die Darstellung von Zeitdauern ein anderes Format gewählt worden.

Gültige Werte für xs:time sind unter anderem:

21:32:52
21:32:52+02:00
19:32:52Z
19:32:52+00:00
21:32:52.12679

Die folgenden Werte sind ungültig:

21:32 (alle Teile müssen angegeben werden)
25:25:10 (der Stundenteil ist außerhalb des zulässigen Bereichs)
-10:00:00 (der Stundenteil ist außerhalb des zulässigen Bereichs)
1:20:10 (alle Ziffern müssen angegeben werden)

Diese Unterstützung für wiederkehrende Zeitpunkte ist ebenfalls stark eingeschränkt. Die Wiederholungsspanne muß ein gregorianischer Kalendertag ein, sie darf nicht beliebig sein.

Wiederkehrende Zeiträume: xs:gDay, xs:gMonth und xs:gMonthDay

Wir haben bereits Zeitpunkte und Zeiträume sowie wiederkehrende Zeitpunkte kennengelernt. Ohne eine Beschreibung wiederkehrender Zeiträume wäre diese Aufstellung nicht vollständig. W3C XML Schema unterstützt drei vordefinierte wiederkehrende Zeiträume, die gregorianischen Kalendermonaten (die jedes Jahr wiederkehren) bzw. Tagen (die jeden Monat oder jedes Jahr wiederkehren) entsprechen. Die Unterstützung für wiederkehrende Zeiträume ist sowohl im Hinblick auf die Wiederholungsspanne (sie kann nur ein gregorianisches Jahr oder ein Monat sein) als auch auf den Zeitraum (die Anfangszeit kann nur ein gregorianischer Kalendertag bzw. -monat sein, die Zeitdauer kann nur ein gregorianischer Kalendermonat bzw. ein gregorianisches Jahr sein) eingeschränkt.

xs:gDay ist ein Zeitraum von einem gregorianischen Kalendertag, der sich jeden gregorianischen Kalendermonat wiederholt. Die lexikalische Darstellung von xs:gDay ist ---DD, wahlweise mit Angabe einer Zeitzone. Gültige Werte für xs:gDay sind unter anderem:

---01
---01Z
---01+02:00
---01-04:00
---15
---31

Die folgenden Werte sind ungültig:

--30- (das Format muß »---DD« lauten)
---35 (der Tag ist außerhalb des zulässigen Bereichs)
---5 (alle Ziffern müssen angegeben werden)
15 (die führenden Zeichen »---« fehlen)

Die Rechenregeln für Datumsangaben und Zeiträume werden auch hier angewendet. Tage werden auf den zulässigen Bereich für jeden Monat »festgenagelt«. In unserem Beispiel »--31« sind die ausgewählten Tage der 31. Januar, der 28. (oder 29.) Februar, der 31. März, der 30. April usw.

xs:gMonthDay ist ein Zeitraum eines gregorianischen Kalendertages, der sich jedes gregorianische Jahr wiederholt. Die lexikalische Darstellung von xs:gMonthDay lautet --MM-DD, wahlweise mit Angabe einer Zeitzone. Gültige Werte für xs:gMonthDay sind unter anderem:

--05-01
--11-01Z
--11-01+02:00
--11-01-04:00
--11-15
--02-29

Die folgenden Werte sind ungültig:

-01-30- (das Format muß --MM-DD lauten)
--01-35 (der Tagesteil ist außerhalb des zulässigen Bereichs)
--1-5 (alle Ziffern müssen angegeben werden)
01-15 (die führenden Zeichen »--« fehlen)

xs:gMonth ist ein Zeitraum von einem gregorianischen Kalendermonat, der sich jedes gregorianische Kalenderjahr wiederholt. Die lexikalische Darstellung von xs:gMonth wird in der Empfehlung als --MM-- definiert, wahlweise unter Angabe einer Zeitzone. Die W3C XML Schema Working Group hat eingestanden, daß dies ein Fehler war und daß vielmehr das von ISO 8601 definierte Format --MM zu verwenden gewesen wäre. Es ist noch nicht entschieden worden, ob das in der Empfehlung beschriebene Format verboten oder nur als veraltet deklariert wird, aber es wird empfohlen, das Format --MM zu verwenden (unter der Annahme, daß die Tools, die Sie verwenden, dieses Format bereits unterstützen). Gültige Werte für xs:gMonth sind unter anderem:

--05
--11Z
--11+02:00
--11-04:00
--02

Die folgenden Werte sind ungültig:

-01- (das Format muß --MM lauten)
--13 (der Monat ist außerhalb des zulässigen Bereichs)
--1 (beide Ziffern müssen angegeben werden)
01 (die führenden Zeichen »--« fehlen)

xs:duration

Naive Programmierer, die glauben, der Begriff der Zeitdauer sei einfach, sollten die Empfehlung lesen. Sie besagt: »xs:duration ist als sechsdimensionaler Raum definiert.« Mathematiker würden dem entgegenhalten, daß dies nicht wirklich stimmte, da die meisten Achsen dieser Dimensionen parallel laufen. Tatsache ist jedoch, daß diese Programmierer eine Zeitdauer von 31 bis zu 34 Tagen festlegen, wenn sie behaupten, eine Entwicklung würde einen Monat und drei Tage benötigen. Der Versuch von W3C XML Schema, sich dieser Probleme über ISO 8601 hinaus anzunehmen, hat dazu geführt, daß der Vergleich von Zeitdauern etwas unbestimmter ist.

Der lexikalische Raum von xs:duration ist das von ISO 8601 definierte Format in der Ausprägung PnYnMnDTnHnMnS , wobei die Großbuchstaben als Trennzeichen dienen, die weggelassen werden können, wenn die entsprechende Zahl nicht auftritt. Ein wichtiger Unterschied gegenüber dem Format für xs:dateTime besteht darin, daß keines der Elemente vorgeschrieben ist und daß keines auf einen bestimmten Bereich beschränkt ist. Daraus ergibt sich die Freiheit, die verwendeten Einheiten selbst zu wählen und auch mehrere zu kombinieren – beispielsweise P1Y2MT123S (1 Jahr, 2 Monate und 123 Sekunden). Diese Flexibilität hat ihren Preis, denn eine solche Zeitdauer ist nicht vollständig definiert: Ein Jahr kann 365 oder 366 Tage haben, und eine Zeitdauer von zwei Monaten dauert zwischen 59 und 62 Tagen. Zeitdauern können nicht immer miteinander verglichen werden, und zwischen Zeitdauern besteht eine Teilordnungsrelation. Wir werden im nächsten Kapitel sehen, daß benutzerdefinierte Datentypen von xs:duration abgeleitet werden können, die die Bestandteile, die für die Beschreibung von Zeiträumen verwendet werden, beschränken und dadurch erreichen können, daß diese Unbestimmtheiten nicht auftreten.

Da der Wert einer Zeitdauer festgelegt ist, sobald ihr Anfangszeitpunkt feststeht, hat die Schema-Arbeitsgruppe die folgenden vier Zeitpunkte benannt, die die größten Abweichungen verursachen, wenn Tage, Monate und andere Komponenten addiert werden:

1696-09-01T00:00:00Z
1697-02-01T00:00:00Z
1903-03-01T00:00:00Z
1903-07-01T00:00:00Z

Die Arbeitsgruppe hat festgelegt, daß der Vergleich von Zeitdauern genau dann undefiniert ist, wenn das Ergebnis des Vergleichs unterschiedlich ausfällt, je nachdem, welcher dieser vier Zeitpunkte als Anfang verwendet wird.

Gültige Werte für xs:duration sind unter anderem:

PT1004199059S
PT130S
PT2M10S
P1DT2S
-P1Y
P1Y2M3DT5H20M30.123S

Die folgenden Werte sind ungültig:

1Y (das führende P fehlt)
P1S (das Trennzeichen T fehlt)
P-1Y (alle Teile müssen nicht-negativ sein)
P1M2Y (es kommt auf die Reihenfolge der Teile an, Y muß vor M stehen)
P1Y-1M (alle Teile müssen nicht-negativ sein)

   

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema XML Schema bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2003 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "XML Schema" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de