D ISO 8601 Date and Time Formats
D.1 ISO 8601 Conventions
The two primitive datatypes described above,
timeDuration, recurringDuration, and the
five derived datatypes timeInstant,
date, time, timePeriod, and
recurringDate use lexical formats inspired by
[ISO 8601]. This appendix provides more detail on the ISO
formats and discusses some deviations from them for the datatypes
defined in this specification.
[ISO 8601] "specifies the representation of dates in the
Gregorian calendar and times and representations of periods of time".
The Gregorian calendar includes dates prior to 1582 (the year it came
into use as an ecclesiastical calendar).
It should be pointed out that the datatypes described in this
specification do not cover all the types of data covered by
[ISO 8601], nor do they support all the lexical
representations for those types of data.
[ISO 8601] lexical formats are described using "pictures"
in which characters are used in place of digits. For
recurringDuration and types derived from it, these characters
have the following meanings:
-
C -- represents a digit used in the thousands and hundreds components,
the "century" component, of the time element "year". Legal values are
from 0 to 9.
-
Y -- represents a digit used in the tens and units components of the time
element "year". Legal values are from 0 to 9.
-
M -- represents a digit used in the time element "month". The two
digits in a MM format can have values from 1 to 12.
-
D -- represents a digit used in the time element "day". The two digits
in a DD format can have values from 1 to 28 if the month value equals 2,
1 to 29 if the month value equals 2 and the year is a leap year, 1 to 30
if the month value equals 4, 6, 9 or 11, and 1 to 31 if the month value
equals 1, 3, 5, 7, 8, 10 or 12.
-
h -- represents a digit used in the time element "hour". The two digits
in a hh format can have values from 0 to 23.
-
m -- represents a digit used in the time element "minute". The two digits
in a mm format can have values from 0 to 59.
-
s -- represents a digit used in the time element "second". The two
digits in a ss format can have values from 0 to 60. In the formats
described in this specification the whole number of seconds may
be followed by decimal seconds to an arbitrary level of precision.
This is represented in the picture by "ss.sss". A value of 60 is allowed
only in the case of leap seconds.
For all the information items indicated by the above characters, leading
zeros are required where indicated.
In addition to the above, certain characters are used as designators
and appear as themselves in lexical formats.
-
T -- is used as time designator to indicate the start of the
representation of the time of day in recurringDuration
and timeInstant
-
Z -- is used as time-zone designator, immediately (without a space)
following a data element expressing the time of day in Coordinated
Universal Time (UTC) in recurringDuration,
timeInstant and time
In the lexical format for timeDuration the following
characters are also used as designators and appear as themselves in
lexical formats:
- P -- is used as the time duration designator, preceding a data element
representing a given duration of time.
- Y -- follows the number of years in a time duration.
- M -- follows the number of months or minutes in a time duration.
- D -- follows the number of days in a time duration.
- H -- follows the number of hours in a time duration.
- S -- follows the number of seconds in a time duration.
The values of the
Year, Month, Day, Hour and Minutes components are not restricted but
allow an arbitrary integer. Similarly, the value of the Seconds component
allows an arbitrary decimal. Thus, the lexical format for
timeDuration and datatypes derived from it
does not follow the alternative
format of § 5.5.3.2.1 of [ISO 8601].
D.2 Truncated and Reduced Formats
[ISO 8601] supports a variety of "truncated" formats in
which some of the characters on the left of specific formats, for example,
the
century, can be omitted.
Truncated formats are, in
general, not permitted for the datatypes defined in this specification
with three exceptions. The time datatype uses
a truncated format for timeInstant. By truncating the date
information we represent an instant of time that recurs every day.
Similarly, the recurringDate and recurringDay
datatypes use left-truncated formats for date.
[ISO 8601] also supports a variety of "reduced" or right-truncated
formats in which some of the characters to the right of specific formats,
such as the
time specification, can be omitted. Right truncated formats are also, in
general,
not permitted for the datatypes defined in this specification
with the following exceptions:
right-truncated representations of timePeriod are used as
lexical representations for date, month,
year and century.
D.3 Deviations from ISO 8601 Formats
D.3.1 Sign Allowed
An optional minus sign is allowed immediately preceding, without a space,
the lexical representations for timeDuration, timeInstant and
date.
D.3.2 No Year Zero
The year "0000" is an illegal year value.
E Regular Expressions
A regular expressionR is a sequence of
characters that denote a set of stringsL(R).
When used to constrain a lexical space, a
regular expressionR asserts that only strings
in L(R) are valid literals for values of that type.
[Definition:] A
regular expression is composed from zero or more
branches, separated by | characters.
|
For all branches S, and for all
regular expressions T, valid
regular expressions R are:
|
Denoting the set of strings L(R) containing:
|
| (empty string) | the set containing just the empty string
|
| S | all strings in L(S) |
| S|T | all strings in L(S) and
all strings in L(T) |
[Definition:] A branch consists
of zero or more pieces, concatenated together.
|
For all pieces S, and for all
branches T, valid
branches R are:
|
Denoting the set of strings L(R) containing:
|
| S | all strings in L(S) |
| ST | all strings st with s in
L(S) and t in L(T) |
[Definition:] A piece is an
atom, possibly followed by a
quantifier.
|
For all atoms S and non-negative
integers n, m such that
n <= m, valid pieces
R are:
|
Denoting the set of strings L(R) containing:
|
| S | all strings in L(S) |
| S? | the empty string, and all strings in
L(S). |
| S* |
All strings in L(S?) and all strings st
with s in L(S*)
and t in L(S). ( all concatenations
of zero or more strings from L(S) ) |
| S+ |
All strings st with s in L(S)
and t in L(S*). ( all concatenations
of one or more strings from L(S) ) |
| S{n,m} |
All strings st with s in L(S)
and t in L(S{n-1,m-1}). ( All
sequences of at least n, and at most m, strings from L(S) ) |
| S{n} |
All strings in L(S{n,n}). ( All
sequences of exactly n strings from L(S) ) |
| S{n,} |
All strings in L(S{n}S*) ( All
sequences of at least n, strings from L(S) ) |
| S{0,m} |
All strings st with s in L(S?)
and t in L(S{0,m-1}). ( All
sequences of at most m, strings from L(S) ) |
| S{0,0} |
The set containing only the empty string
|
NOTE:
The regular expression language in the Perl Programming Language
[Perl] does not include a quantifier of the form
S{,m), since it is logically equivalent to S{0,m}.
We have, therefore, left this logical possibility out of the regular
expression language defined by this specification. We welcome
further input from implementors and schema authors on this issue.
[Definition:] A quantifier
is one of ?, *, +,
{n,m} or {n,}, which have the meanings
defined in the table above.
[Definition:] An atom is either a
normal character, a character class, or
a parenthesized regular expression.
[Definition:] A metacharacter
is either ., \, ?,
*, +, {, }(, ), [ or ].
These characters have special meanings in regular expressions,
but can be escaped to form atoms that denote the
sets of strings containing only themselves, i.e., an escaped
metacharacter behaves like a normal character.
[Definition:] A
normal character is any XML character that is not a
metacharacter. In regular expressions, a normal character is an
atom that denotes the singleton set of strings containing only itself.
Note that a normal character can be represented either as
itself, or with a character
reference.
E.1 Character Classes
[Definition:] A
character class is an atomR that identifies a set of charactersC(R). The set of strings L(R) denoted by a
character class R contains one single-character string
"c" for each character c in C(R).
A character class is either a character class escape or a
character class expression.
[Definition:] A
character class expression is a character group surrounded
by [ and ] characters. For all character
groups G, [G] is a valid character class
expression, identifying the set of characters
C([G]) = C(G).
[Definition:] A
character group is either positive character group,
a negative character group, or a character class subtraction.
[Definition:]
A positive character group consists of one or more
character ranges or character class escapes, concatenated
together. A positive character group identifies the set of
characters containing all of the characters in all of the sets identified
by its constituent ranges or escapes.
[Definition:]
A negative character group is a
positive character group preceded by the ^ character.
For all positive character groups P, ^P
is a valid negative character group, and C(^P)
contains all XML characters that are not in C(P).
[Definition:] A
character class subtraction is a character class expression
subtracted from a positive character group or
negative character group, using the - character.
For any positive character group or
negative character groupG, and any
character class expressionC, G-C is a valid
character class subtraction, identifying the set of all characters in
C(G) that are not also in C(C).
[Definition:] A
character rangeR identifies a set of
characters C(R) containing all XML characters with Unicode
code points in a specified range.
A single XML character is a character range that identifies
the set of characters containing only itself. All XML characters are valid
character ranges, except as follows:
A character range may also be written
in the form s-e, identifying the set that contains all XML characters
with Unicode code points greater than or equal to the code point
of s, but not greater than the code point of e.
s-e is a valid character range iff:
NOTE:
The code point of a single character escape is the code point of the
single character in the set of characters that it identifies.
E.1.1 Character Class Escapes
[Definition:]
A character class escape is a short sequence of characters
that identifies predefined character class. The valid character
class escapes include the single character escapes, the
multi-character escapes, and the category escapes.
[Definition:] A
single character escape identifies a set containing a only
one character -- usually because that character is difficult or
impossible to write directly into a regular expression.
|
The valid single character escapes are:
|
Identifying the set of characters C(R) containing:
|
\n | the newline character (#xA) |
\r | the return character (#xD) |
\t | the tab character (#x9) |
\\ | \ |
\| | | |
\. | . |
\- | - |
\^ | ^ |
\? | ? |
\* | * |
\+ | + |
\{ | { |
\} | } |
\( | ( |
\) | ) |
\[ | [ |
\] | ] |
[Definition:] [Unicode3] defines a number of character properties
and provides mappings from code points to specific character properties.
The set containing all characters that have property X,
can be identified with a category escape\p{X}.
The complement of this set is specified with the
category escape\P{X}.
([\P{X}] = [^\p{X}]).
NOTE: [Unicode3] is subject to future revision. For example, the
mapping from code points to character properties might be updated.
All minimally conforming processors must
support the character properties defined in the version of the Unicode
Standard that is current at the time this specification became a W3C
Recommendation. However, implementors are encouraged to support the
character properties defined in any future version of the Unicode Standard.
NOTE:
The syntax \p{X} is the same as that used in
[Perl 5.6].
The following table specifies the main character properties (for more
information, see Chapter 4 of [Unicode3]).
| Category | Property | Meaning |
| Letters | L | All Letters |
| Lu | Uppercase |
| Ll | Lowercase |
| Lt | Titlecase |
| Lm | Modifier |
| Lo | Other |
| |
| Marks | M | All Marks |
| Mn | Non-Spacing |
| Mc | Spacing Combining |
| Me | Enclosing |
| |
| Numbers | N | All Numbers |
| Nd | Decimal Digit |
| Nl | Letter |
| No | Other |
| |
| Punctuation | P | All Punctuation |
| Pc | Connector |
| Pd | Dash |
| Ps | Open |
| Pe | Close |
| Pi | Initial quote
(can behave like Ps or Pe depending on usage) |
| Pf | Final quote
(can behave like Ps or Pe depending on usage) |
| Po | Other |
| |
| Separators | Z | All Separators |
| Zs | Space |
| Zl | Line |
| Zp | Paragraph |
| |
| Symbols | S | All Symbols |
| Sm | Math |
| Sc | Currency |
| Sk | Modifier |
| So | Other |
| |
| Other | C | All Others |
| Cc | Control |
| Cf | Format |
| Co | Private Use |
| Cn | Not Assigned |
NOTE:
The properties mentioned exclude the Cs property described
in Chapter 4 of [Unicode3]. The Cs property
identifies [Unicode3] "surrogate" characters, which do not
occur at the level of the "character abstraction" that XML instance documents
operate on.
[Definition:] [Unicode3] groups code points into a number of blocks
such as Basic Latin (i.e., ASCII), Latin-1 Supplement, Hangul Jamo,
CJK Compatibility, etc.
The set containing all characters that have block name X
(with all white space stripped out),
can be identified with a block escape\p{IsX}.
The compliment of this set is specified with the
block escape\P{IsX}.
([\P{IsX}] = [^\p{IsX}]).
NOTE: [Unicode3] is subject to future revision. For example, the
grouping of code points into blocks might be updated.
All minimally conforming processors must
support the blocks defined in the version of the Unicode
Standard that is current at the time this specification became a W3C
Recommendation. However, implementors are encouraged to support the
blocks defined in any future version of the Unicode Standard.
NOTE:
The syntax \p{IsX} is the same as that used in
[Perl 5.6].
For example, the block escape for identifying the
ASCII characters is \p{IsBasicLatin}.
[Definition:] A
multi-character escape provides a simple way to identify
a commonly used set of characters:
| Character sequence | Equivalent character class |
| . | [^\n\r] |
| \s | [#x20\t\n\r] |
| \S | [^\s] |
| \i | [\p{L}\p{Nl}:_] |
| \I | [^\i] |
| \c | the set of characters matched by
NameChar |
| \C | [^\c] |
| \d | \p{Nd} |
| \D | [^\d] |
| \w |
[#x0000-#x10FFFF]-[\p{P}\p{S}\p{C}]
(all characters except the set of "punctuation",
"separator" and "control" characters)
|
| \W | [^\w] |
NOTE:
The regular expression language defined here does not
attempt to provide a general solution to "regular expressions" over
[Unicode3] strings. In particular, it does not easily provide
for matching sequences of base characters and combining marks.
The language is targeted at support of "Level 1" features as defined in
[Unicode Regular Expression Guidelines]. It is hoped that future versions of this
specification will provide support for "Level 2" features.
Ed. Note: Priority Feedback Request
Future versions of this specification might allow non-significant white space
embedded within a regular expression. The
XML Schema Working
Group welcomes feedback from implementors and schema authors on
the advisability of including such white space.
G Acknowledgements (non-normative)
The following have contributed material to this draft:
- David Fallside, IBM
- Scott Lawrence, Agranat Systems
- Andrew Layman, Microsoft
- Eve L. Maler, Sun Microsystems
The editors acknowledge the members of the XML Schema Working Group, the members of other W3C Working Groups, and industry experts in other
forums who have contributed directly or indirectly to the process or content of
creating this document. The Working Group is particularly grateful to Lotus
Development Corp. and IBM for providing teleconferencing facilities.
The current members of the XML Schema Working Group are:
Jim Barnette, Defense Information Systems Agency (DISA); David Beech, Oracle Corp.; Paul V. Biron, Health Level Seven; Don Box, DevelopMentor; Allen Brown, Microsoft; Lee Buck, TIBCO Extensibility; Charles E. Campbell, Informix; Wayne Carr, Intel; Peter Chen, Bootstrap Alliance and LSU; David Cleary, Progress Software; Mike Cokus, MITRE; Dan Connolly, W3C (staff contact); Roger L. Costello, MITRE; Ugo Corda, Xerox; Haavard Danielson, Progress Software; David Ezell, Hewlett Packard Company; David Fallside, IBM; Matthew Fuchs, Commerce One; Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd); Paul Grosso, ArborText, Inc; Martin Gudgin, DevelopMentor; Dave Hollander, Contivo (co-chair); Mary Holstege, Calico Commerce; Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd); Rick Jelliffe, Academia Sinica; Andrew Layman, Microsoft; Dmitry Lenkov, Hewlett Packard Company; Ashok Malhotra, IBM; Murray Maloney, Muzmo Communication, acting for Commerce One; John McCarthy, Lawrence Berkeley National Laboratory; Noah Mendelsohn, Lotus Development Corporation; Don Mullen, TIBCO Extensibility; Alex Milowski, Lexica LLC; Frank Olken, Lawrence Berkeley National Laboratory; Dave Peterson, Graphic Communications Association; Jonathan Robie, Software AG; Lew Shannon, NCR; C. M. Sperberg-McQueen, W3C (co-chair); Bob Streich, Calico Commerce; Henry S. Thompson, University of Edinburgh; Matt Timmermans, Microstar; Jim Trezzo, Oracle Corp.; Mark Tucker, Health Level Seven; Asir S. Vedamuthu, webMethods, Inc; Priscilla Walmsley, XMLSolutions; Norm Walsh, Sun Microsystems; Aki Yoshida, SAP AG
The XML Schema Working Group has benefited in its work from the
participation and contributions of a number of people not currently
members of the Working Group, including
in particular those named below. Affiliations given are those current at
the time of their work with the WG.
Paula Angerstein, Vignette Corporation; Gabe Beged-Dov, Rogue Wave Software; Greg Bumgardner, Rogue Wave Software; Dean Burson, Lotus Development Corporation; Andrew Eisenberg, Progress Software; Rob Ellman, Calico Commerce; George Feinberg, Object Design; Charles Frankston, Microsoft; Ernesto Guerrieri, Inso; Michael Hyman, Microsoft; Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd); Dianne Kennedy, Graphic Communications Association; Janet Koenig, Sun Microsystems; Setrag Khoshafian, Technology Deployment International (TDI); Ara Kullukian, Technology Deployment International (TDI); Murata Makoto, Xerox; Eve Maler, Sun Microsystems; Chris Olds, Wall Data; Shriram Revankar, Xerox; Mark Reinhold, Sun Microsystems; John C. Schneider, MITRE; William Shea, Merrill Lynch; Ralph Swick, W3C; Tony Stewart, Rivcom; Steph Tryphonas, Microstar