D ISO 8601 Date and Time Formats
D.1 ISO 8601 Conventions
The two primitive datatypes described above,
timeDuration, recurringDuration, and the
five derived dataypes 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".
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. Specifically, we permit only
a single lexical representation for each datatype.
[ISO 8601] lexical formats are described using "pictures"
in which characters are used in place of digits. 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 12.
-
m -- represents a digit used in the time element "minute". The two digits
in a mm format can have values from 0 to 60.
-
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".
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
D.2 Truncated and Reduced Formats -- Changed Heading for Section
[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 timeInstant and
date. The year "0000" is an illegal year value.
E Regular Expressions
A regular expression R is a sequence of
characters that denote a set of strings L(R).
When used to constrain a lexical space, a
regular expression R 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{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{n,} |
All strings in L(S{n,n}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 it logicall 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 atom
R that identifies a set of characters
C(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 group G, and any
character class expression C, 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 range R 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 chacters 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 (
) |
\r |
the return character (
) |
\t |
the tab character (	) |
\\ |
\ |
\. |
. |
\- |
- |
\^ |
^ |
\? |
? |
\* |
* |
\+ |
+ |
\{ |
{ |
\} |
} |
\( |
( |
\) |
) |
\[ |
[ |
\] |
] |
[Definition:] The Unicode Standard
[Unicode] defines a number of character properties
and provides mappings from code points to specific character properties.
The set containing of all characters that have property X,
may be identified with a category escape \p{X}.
The compliment of this set may be specified with the
category escape \P{X}.
([\P{X}] = [^\p{X}]).
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 [Unicode]).
| 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
(may behave like Ps or Pe depending on usage) |
| Pf |
Final quote
(may 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 |
| Cs |
Surrogate |
| Co |
Private Use |
| Cn |
Not Assigned |
[Definition:] The Unicode Standard
[Unicode] groups code points into a number of blocks
such as Basic Latin (i.e., ASCII), Latin-1 Suppliment, Hangul Jamo,
CJK Compatibility, etc.
The set containing of all characters that have block name X
(with all whitespace stripped out),
may be identified with a block escape \p{IsX}.
The compliment of this set may be specified with the
block escape \P{IsX}.
([\P{IsX}] = [^\p{IsX}]).
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 |
[ \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 |
[�-]-[\p{P}\p{S}\p{C}]
(all characters except the set of "punctuation",
"separator" and "control" characters)
|
| \W |
[^\w] |
G Acknowledgments (non-normative)
The following have contributed material to this draft:
- Matt Timmermans
- Mark Reinhold
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, Extensibility; Charles E. Campbell, Informix; Peter Chen, Bootstrap Alliance and LSU; David Cleary, Progress Software; Dan Connolly, W3C (staff contact); Roger L. Costello, MITRE; Ugo Corda, Xerox; Andrew Eisenberg, 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, CommerceNet (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; Eve Maler, Sun Microsystems; Ashok Malhotra, IBM; Murray Maloney, Commerce One; John McCarthy, Lawrence Berkeley National Laboratory; Noah Mendelsohn, Lotus Development Corporation; Don Mullen, Extensibility; Frank Olken, Lawrence Berkeley National Laboratory; Dave Peterson, Graphic Communications Association; Mark Reinhold, Sun Microsystems; Jonathan Robie, Software AG; John C. Schneider, MITRE; 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.; Steph Tryphonas, Microstar; Mark Tucker, Health Level Seven; Asir S. Vedamuthu, webMethods, Inc; Priscilla Walmsley, XMLSolutions; Norm Walsh, ArborText, Inc; 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; 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; Chris Olds, Wall Data; Shriram Revankar, Xerox; William Shea, Merrill Lynch; Ralph Swick, W3C; Tony Stewart, Rivcom