3.2.3 decimal
[Definition:] decimal
represents a subset of the real numbers, which can be represented by decimal numerals.
The ·value space· of decimal
is the set of
numbers that can be obtained by multiplying an integer by a non-positive
power of ten, i.e., expressible as i × 10^-n
where i and n are integers
and n >= 0.
Precision is not reflected in this value space;
the number 2.0 is not distinct from the number 2.00.
The ·order-relation· on decimal
is the order relation on real numbers, restricted
to this subset.
Note:
All
·minimally conforming· processors
·must·
support decimal numbers with a minimum of 18 decimal digits (i.e., with a
·totalDigits· of 18). However,
·minimally conforming· processors
·may·
set an application-defined limit on the maximum number of decimal digits
they are prepared to support, in which case that application-defined
maximum number
·must· be clearly documented.
3.2.3.1 Lexical representation
decimal has a lexical representation
consisting of a finite-length sequence of decimal digits (#x30-#x39) separated
by a period as a decimal indicator.
An optional leading sign is allowed.
If the sign is omitted, "+" is assumed. Leading and trailing zeroes are optional.
If the fractional part is zero, the period and following zero(es) can
be omitted.
For example: -1.23, 12678967.543233, +100000.00, 210.
3.2.3.2 Canonical representation
The canonical representation for decimal is defined by
prohibiting certain options from the
Lexical representation (§3.2.3.1). Specifically, the preceding
optional "+" sign is prohibited. The decimal point is required. Leading and
trailing zeroes are prohibited subject to the following: there must be at least
one digit to the right and to the left of the decimal point which may be a zero.
3.2.4 float
[Definition:] float
is patterned after the IEEE single-precision 32-bit floating point type
[IEEE 754-1985]. The basic ·value space· of
float consists of the values
m × 2^e, where m
is an integer whose absolute value is less than
2^24, and e is an integer
between -149 and 104, inclusive. In addition to the basic
·value space· described above, the
·value space· of float also contains the
following
three
special values:
positive and negative infinity and not-a-number
(NaN).
The ·order-relation· on float
is: x < y iff y - x is positive
for x and y in the value space.
Positive infinity is greater than all other non-NaN values.
NaN equals itself but is ·incomparable· with (neither greater than nor less than)
any other value in the ·value space·.
Note:
"Equality" in this Recommendation is defined to be "identity" (i.e., values that
are identical in the
·value space· are equal and vice versa).
Identity must be used for the few operations that are defined in this Recommendation.
Applications using any of the datatypes defined in this Recommendation may use different
definitions of equality for computational purposes;
[IEEE 754-1985]-based computation systems
are examples. Nothing in this Recommendation should be construed as requiring that
such applications use identity as their equality relationship when computing.
Any value
·incomparable· with the value used for the four bounding facets
(
·minInclusive·,
·maxInclusive·,
·minExclusive·, and
·maxExclusive·) will be
excluded from the resulting restricted
·value space·. In particular,
when "NaN" is used as a facet value for a bounding facet, since no other
float values are
·comparable· with it, the result is a
·value space·
either having NaN as its only member (the inclusive cases) or that is empty
(the exclusive cases). If any other value is used for a bounding facet,
NaN will be excluded from the resulting restricted
·value space·;
to add NaN back in requires union with the NaN-only space.
This datatype differs from that of
[IEEE 754-1985] in that there is only one
NaN and only one zero. This makes the equality and ordering of values in the data
space differ from that of
[IEEE 754-1985] only in that for schema purposes NaN = NaN.
A literal in the ·lexical space· representing a
decimal number d maps to the normalized value
in the ·value space· of float that is
closest to d in the sense defined by
[Clinger, WD (1990)]; if d is
exactly halfway between two such values then the even value is chosen.
3.2.4.1 Lexical representation
float values have a lexical representation
consisting of a mantissa followed, optionally, by the character
"E" or "e", followed by an exponent. The exponent ·must·
be an integer. The mantissa must be a decimal number. The representations
for exponent and mantissa must follow the lexical rules for
integer and decimal. If the "E" or "e" and
the following exponent are omitted, an exponent value of 0 is assumed.
The special values
positive
and negative infinity and not-a-number have lexical representations
INF, -INF and
NaN, respectively.
Lexical representations for zero may take a positive or negative sign.
For example, -1E4, 1267.43233E12, 12.78e-2, 12
, -0, 0
and INF are all legal literals for float.
3.2.4.2 Canonical representation
The canonical representation for float is defined by
prohibiting certain options from the
Lexical representation (§3.2.4.1). Specifically, the exponent
must be indicated by "E". Leading zeroes and the preceding optional "+" sign
are prohibited in the exponent.
If the exponent is zero, it must be indicated by "E0".
For the mantissa, the preceding optional "+" sign is prohibited
and the decimal point is required.
Leading and trailing zeroes are prohibited subject to the following:
number representations must
be normalized such that there is a single digit
which is non-zero
to the left of the decimal point and at least a single digit to the
right of the decimal point
unless the value being represented is zero. The canonical
representation for zero is 0.0E0.
3.2.5 double
[Definition:] The double
datatype
is patterned after the
IEEE double-precision 64-bit floating point
type [IEEE 754-1985]. The basic ·value space·
of double consists of the values
m × 2^e, where m
is an integer whose absolute value is less than
2^53, and e is an
integer between -1075 and 970, inclusive. In addition to the basic
·value space· described above, the
·value space· of double also contains
the following
three
special values:
positive and negative infinity and not-a-number
(NaN).
The ·order-relation· on double
is: x < y iff y - x is positive
for x and y in the value space.
Positive infinity is greater than all other non-NaN values.
NaN equals itself but is ·incomparable· with (neither greater than nor less than)
any other value in the ·value space·.
Note:
"Equality" in this Recommendation is defined to be "identity" (i.e., values that
are identical in the
·value space· are equal and vice versa).
Identity must be used for the few operations that are defined in this Recommendation.
Applications using any of the datatypes defined in this Recommendation may use different
definitions of equality for computational purposes;
[IEEE 754-1985]-based computation systems
are examples. Nothing in this Recommendation should be construed as requiring that
such applications use identity as their equality relationship when computing.
Any value
·incomparable· with the value used for the four bounding facets
(
·minInclusive·,
·maxInclusive·,
·minExclusive·, and
·maxExclusive·) will be
excluded from the resulting restricted
·value space·. In particular,
when "NaN" is used as a facet value for a bounding facet, since no other
double values are
·comparable· with it, the result is a
·value space·
either having NaN as its only member (the inclusive cases) or that is empty
(the exclusive cases). If any other value is used for a bounding facet,
NaN will be excluded from the resulting restricted
·value space·;
to add NaN back in requires union with the NaN-only space.
This datatype differs from that of
[IEEE 754-1985] in that there is only one
NaN and only one zero. This makes the equality and ordering of values in the data
space differ from that of
[IEEE 754-1985] only in that for schema purposes NaN = NaN.
A literal in the ·lexical space· representing a
decimal number d maps to the normalized value
in the ·value space· of double that is
closest to d; if d is
exactly halfway between two such values then the even value is chosen.
This is the best approximation of d
([Clinger, WD (1990)], [Gay, DM (1990)]), which is more
accurate than the mapping required by [IEEE 754-1985].
3.2.5.1 Lexical representation
double values have a lexical representation
consisting of a mantissa followed, optionally, by the character "E" or
"e", followed by an exponent. The exponent ·must· be
an integer. The mantissa must be a decimal number. The representations
for exponent and mantissa must follow the lexical rules for
integer and decimal. If the "E" or "e"
and the following exponent are omitted, an exponent value of 0 is assumed.
The special values
positive
and negative infinity and not-a-number have lexical representations
INF, -INF and
NaN, respectively.
Lexical representations for zero may take a positive or negative sign.
For example, -1E4, 1267.43233E12, 12.78e-2, 12
, -0, 0
and INF
are all legal literals for double.
3.2.5.2 Canonical representation
The canonical representation for double is defined by
prohibiting certain options from the
Lexical representation (§3.2.5.1). Specifically, the exponent
must be indicated by "E". Leading zeroes and the preceding optional "+" sign
are prohibited in the exponent.
If the exponent is zero, it must be indicated by "E0".
For the mantissa, the preceding optional "+" sign is prohibited
and the decimal point is required.
Leading and trailing zeroes are prohibited subject to the following:
number representations must
be normalized such that there is a single digit
which is non-zero
to the left of the decimal point and at least a single digit to the
right of the decimal point
unless the value being represented is zero. The canonical
representation for zero is 0.0E0.
3.2.6 duration
[Definition:]
duration represents a duration of time.
The ·value space· of duration is
a six-dimensional space where the coordinates
designate the Gregorian year, month, day, hour, minute, and second components defined in
§ 5.5.3.2 of [ISO 8601],
respectively. These components are ordered
in their significance by their order of appearance i.e. as year, month, day,
hour, minute, and second.
Note:
All
·minimally conforming· processors
·must·
support year values with a minimum of 4 digits (i.e.,
YYYY) and a minimum fractional second precision of milliseconds or three decimal digits (i.e.
s.sss). However,
·minimally conforming· processors
·may·
set an application-defined limit on the maximum number of digits
they are prepared to support in these two cases, in which case that application-defined
maximum number
·must· be clearly documented.
3.2.6.1 Lexical representation
The lexical representation for duration is the
[ISO 8601] extended format PnYn
MnDTnH nMnS, where
nY represents the number of years, nM the
number of months, nD the number of days, 'T' is the
date/time separator, nH the number of hours,
nM the number of minutes and nS the
number of seconds. The number of seconds can include decimal digits
to arbitrary precision.
The values of the
Year, Month, Day, Hour and Minutes components are not restricted but
allow an arbitrary
unsigned integer, i.e., an integer that
conforms to the pattern [0-9]+..
Similarly, the value of the Seconds component
allows an arbitrary unsigned decimal.
Following [ISO 8601], at least one digit must
follow the decimal point if it appears. That is, the value of the Seconds component
must conform to the pattern [0-9]+(\.[0-9]+)?.
Thus, the lexical representation of
duration does not follow the alternative
format of § 5.5.3.2.1 of [ISO 8601].
An optional preceding minus sign ('-') is
allowed, to indicate a negative duration. If the sign is omitted a
positive duration is indicated. See also ISO 8601 Date and Time Formats (§D).
For example, to indicate a duration of 1 year, 2 months, 3 days, 10
hours, and 30 minutes, one would write: P1Y2M3DT10H30M.
One could also indicate a duration of minus 120 days as:
-P120D.
Reduced precision and truncated representations of this format are allowed
provided they conform to the following:
-
If the number of years, months, days, hours, minutes, or seconds in any
expression equals zero, the number and its corresponding designator ·may·
be omitted. However, at least one number and its designator ·must·
be present.
-
The seconds part ·may· have a decimal fraction.
-
The designator 'T' must
be absent if and only if all of the time items are absent.
The designator 'P' must always be present.
For example, P1347Y, P1347M and P1Y2MT2H are all allowed;
P0Y1347M and P0Y1347M0D are allowed. P-1347M is not allowed although
-P1347M is allowed. P1Y2MT is not allowed.
3.2.6.2 Order relation on duration
In general, the ·order-relation· on duration
is a partial order since there is no determinate relationship between certain
durations such as one month (P1M) and 30 days (P30D).
The ·order-relation·
of two duration values x and
y is x < y iff s+x < s+y
for each qualified dateTime s
in the list below. These values for s cause the greatest deviations in the addition of
dateTimes and durations. Addition of durations to time instants is defined
in Adding durations to dateTimes (§E).
- 1696-09-01T00:00:00Z
- 1697-02-01T00:00:00Z
- 1903-03-01T00:00:00Z
- 1903-07-01T00:00:00Z
The following table shows the strongest relationship that can be determined
between example durations. The symbol <> means that the order relation is
indeterminate. Note that because of leap-seconds, a seconds field can vary
from 59 to 60. However, because of the way that addition is defined in
Adding durations to dateTimes (§E), they are still totally ordered.
| | Relation |
|---|
| P1Y | > P364D | <> P365D | | <> P366D | < P367D |
| P1M | > P27D | <> P28D | <> P29D | <> P30D | <> P31D | < P32D |
| P5M | > P149D | <> P150D | <> P151D | <> P152D | <> P153D | < P154D |
Implementations are free to optimize the computation of the ordering relationship. For example, the following table can be used to
compare durations of a small number of months against days.
| | Months | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ... |
|---|
| Days | Minimum | 28 | 59 | 89 | 120 | 150 | 181 | 212 | 242 | 273 | 303 | 334 | 365 | 393 | ... |
|---|
| Maximum | 31 | 62 | 92 | 123 | 153 | 184 | 215 | 245 | 276 | 306 | 337 | 366 | 397 | ... |
|---|
3.2.6.4 Totally ordered durations
Certain derived datatypes of durations can be guaranteed have a total order. For
this, they must have fields from only one row in the list below and the time zone
must either be required or prohibited.
- year, month
- day, hour, minute, second
For example, a datatype could be defined to correspond to the
[SQL] datatype Year-Month interval that required a four digit
year field and a two digit month field but required all other fields to be unspecified. This datatype could be defined as below and would have a total order.
<simpleType name='SQL-Year-Month-Interval'>
<restriction base='duration'>
<pattern value='P\p{Nd}{4}Y\p{Nd}{2}M'/>
</restriction>
</simpleType>
3.2.7 dateTime
[Definition:]
dateTime values may be viewed as objects with integer-valued
year, month, day, hour and minute properties, a decimal-valued second property,
and a boolean timezoned property.
Each such object also has one decimal-valued
method or computed property, timeOnTimeline, whose value is always a decimal
number; the values are dimensioned in seconds, the integer 0 is
0001-01-01T00:00:00 and the value of timeOnTimeline for other dateTime
values is computed using the Gregorian algorithm as modified for leap-seconds.
The timeOnTimeline values form two related "timelines", one for timezoned
values and one for non-timezoned values.
Each timeline is a copy of the ·value space· of decimal,
with integers given units of seconds.
The ·value space· of
dateTime is closely related to the dates and times described in ISO 8601.
For clarity, the text above specifies a particular origin point for the
timeline.
It should be noted, however, that schema processors need not expose the
timeOnTimeline value to schema users, and there is no requirement that a
timeline-based implementation use the particular origin described here in
its internal representation.
Other interpretations of the ·value space· which lead to the
same results (i.e., are isomorphic) are of course acceptable.
All timezoned times are Coordinated Universal Time (UTC, sometimes called
"Greenwich Mean Time"). Other timezones indicated in lexical representations
are converted to UTC during conversion of literals to values.
"Local" or untimezoned times are presumed to be the time in the timezone of some
unspecified locality as prescribed by the appropriate legal authority;
currently there are no legally prescribed timezones which are durations
whose magnitude is greater than 14 hours. The value of each numeric-valued property
(other than timeOnTimeline) is limited to the maximum value within the interval
determined by the next-higher property. For example, the day value can never be 32,
and cannot even be 29 for month 02 and year 2002 (February 2002).
Note:
The date and time datatypes described in this recommendation were inspired
by
[ISO 8601]. '0001' is the lexical representation of the year 1 of the Common Era
(1
CE, sometimes written "AD 1" or "1 AD"). There is no year 0, and '0000' is not a valid lexical representation. '-0001' is the lexical representation of the year 1 Before
Common Era (1 BCE, sometimes written "1 BC").
Those using this (1.0) version of this Recommendation to
represent negative years should be aware that the interpretation of lexical
representations beginning with a
'-' is likely to change in
subsequent versions.
[ISO 8601]
makes no mention of the year 0; in
[ISO 8601:1998 Draft Revision]
the form '0000' was disallowed and this recommendation disallows it as well.
However,
[ISO 8601:2000 Second Edition], which became available just as we were completing version
1.0, allows the form '0000', representing the year 1 BCE. A number of external commentators
have also suggested that '0000' be
allowed, as the lexical representation for 1 BCE, which is the normal usage in
astronomical contexts.
It is the intention of the XML Schema
Working Group to allow '0000' as a lexical representation in the
dateTime,
date,
gYear, and
gYearMonth datatypes in a subsequent version
of this Recommendation. '0000' will be the lexical representation of 1
BCE (which is a leap year), '-0001' will become the lexical representation of 2
BCE (not 1 BCE as in this (1.0) version), '-0002' of 3 BCE, etc.
Note: See the conformance note in
(§3.2.6) which
applies to this datatype as well.
3.2.7.1 Lexical representation
The ·lexical space· of dateTime consists of
finite-length sequences of characters of the form:
'-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?,
where
- '-'? yyyy is a four-or-more digit optionally negative-signed
numeral that represents the year; if more than four digits, leading zeros
are prohibited, and '0000' is prohibited (see the Note above (§3.2.7); also note that a plus sign is not permitted);
- the remaining '-'s are separators between parts of the date portion;
- the first mm is a two-digit numeral that represents the month;
- dd is a two-digit numeral that represents the day;
- 'T' is a separator indicating that time-of-day follows;
- hh is a two-digit numeral that represents the hour; '24' is permitted if the
minutes and seconds represented are zero, and the dateTime value so
represented is the first instant of the following day (the hour property of a
dateTime object in the ·value space· cannot have
a value greater than 23);
- ':' is a separator between parts of the time-of-day portion;
- the second mm is a two-digit numeral that represents the minute;
- ss is a two-integer-digit numeral that represents the
whole seconds;
- '.' s+ (if present) represents the
fractional seconds;
- zzzzzz (if present) represents the timezone (as described below).
For example, 2002-10-10T12:00:00-05:00 (noon on 10 October 2002, Central Daylight
Savings Time as well as Eastern Standard Time in the U.S.) is 2002-10-10T17:00:00Z,
five hours later than 2002-10-10T12:00:00Z.
For further guidance on arithmetic with dateTimes and durations,
see Adding durations to dateTimes (§E).
3.2.7.2 Canonical representation
Except for trailing fractional zero digits in the seconds representation,
'24:00:00' time representations, and timezone (for timezoned values), the mapping
from literals to values is one-to-one. Where there is more than
one possible representation, the canonical representation is as follows:
- The 2-digit numeral representing the hour must not be '
24'; - The fractional second string, if present, must not end in '
0'; - for timezoned values, the timezone must be
represented with '
Z'
(All timezoned dateTime values are UTC.).
3.2.7.3 Timezones
Timezones are durations with (integer-valued) hour and minute properties
(with the hour magnitude limited to at most 14, and the minute magnitude
limited to at most 59, except that if the hour magnitude is 14, the minute
value must be 0); they may be both positive or both negative.
The lexical representation of a timezone is a string of the form:
(('+' | '-') hh ':' mm) | 'Z',
where
- hh is a two-digit numeral (with leading zeros as required) that
represents the hours,
- mm is a two-digit numeral that represents the minutes,
- '+' indicates a nonnegative duration,
- '-' indicates a nonpositive duration.
The mapping so defined is one-to-one, except that '+00:00', '-00:00', and 'Z'
all represent the same zero-length duration timezone, UTC; 'Z' is its canonical
representation.
When a timezone is added to a UTC dateTime, the result is the date
and time "in that timezone". For example, 2002-10-10T12:00:00+05:00 is
2002-10-10T07:00:00Z and 2002-10-10T00:00:00+05:00 is 2002-10-09T19:00:00Z.
3.2.7.4 Order relation on dateTime
dateTime value objects on either timeline are totally ordered by their timeOnTimeline
values; between the two timelines, dateTime value objects are ordered by their
timeOnTimeline values when their timeOnTimeline values differ by more than
fourteen hours, with those whose difference is a duration of 14 hours or less
being ·incomparable·.
In general, the ·order-relation· on dateTime
is a partial order since there is no determinate relationship between certain
instants. For example, there is no determinate
ordering between
(a)
2000-01-20T12:00:00 and (b) 2000-01-20T12:00:00Z. Based on
timezones currently in use, (c) could vary from 2000-01-20T12:00:00+12:00 to
2000-01-20T12:00:00-13:00. It is, however, possible for this range to expand or
contract in the future, based on local laws. Because of this, the following
definition uses a somewhat broader range of indeterminate values: +14:00..-14:00.
The following definition uses the notation S[year] to represent the year
field of S, S[month] to represent the month field, and so on. The notation (Q
& "-14:00") means adding the timezone -14:00 to Q, where Q did not
already have a timezone. This is a logical explanation of the process. Actual
implementations are free to optimize as long as they produce the same results.
The ordering between two dateTimes P and Q is defined by the following
algorithm:
A.Normalize P and Q. That is, if there is a timezone present, but
it is not Z, convert it to Z using the addition operation defined in
Adding durations to dateTimes (§E)
- Thus 2000-03-04T23:00:00+03:00 normalizes to 2000-03-04T20:00:00Z
B. If P and Q either both have a time zone or both do not have a time
zone, compare P and Q field by field from the year field down to the
second field, and return a result as soon as it can be determined. That is:
- For each i in {year, month, day, hour, minute, second}
- If P[i] and Q[i] are both not specified, continue to the next i
- If P[i] is not specified and Q[i] is, or vice versa, stop and return
P <> Q
- If P[i] < Q[i], stop and return P < Q
- If P[i] > Q[i], stop and return P > Q
- Stop and return P = Q
C.Otherwise, if P contains a time zone and Q does not, compare
as follows:
- P < Q if P < (Q with time zone +14:00)
- P > Q if P > (Q with time zone -14:00)
- P <> Q otherwise, that is, if (Q with time zone +14:00) < P < (Q with time zone -14:00)
D. Otherwise, if P does not contain a time zone and Q does, compare
as follows:
- P < Q if (P with time zone -14:00) < Q.
- P > Q if (P with time zone +14:00) > Q.
- P <> Q otherwise, that is, if (P with time zone +14:00) < Q < (P with time zone -14:00)
Examples:
| Determinate | Indeterminate |
|---|
| 2000-01-15T00:00:00 < 2000-02-15T00:00:00 | 2000-01-01T12:00:00 <>
1999-12-31T23:00:00Z |
| 2000-01-15T12:00:00 < 2000-01-16T12:00:00Z | 2000-01-16T12:00:00 <>
2000-01-16T12:00:00Z |
| | 2000-01-16T00:00:00 <> 2000-01-16T12:00:00Z |
3.2.7.5 Totally ordered dateTimes
Certain derived types from dateTime
can be guaranteed have a total order. To
do so, they must require that a specific set of fields are always specified, and
that remaining fields (if any) are always unspecified. For example, the date
datatype without time zone is defined to contain exactly year, month, and day.
Thus dates without time zone have a total order among themselves.
3.2.8 time
[Definition:] time
represents an instant of time that recurs every day. The
·value space· of time is the space
of time of day values as defined in § 5.3 of
[ISO 8601]. Specifically, it is a set of zero-duration daily
time instances.
Since the lexical representation allows an optional time zone
indicator, time values are partially ordered because it may
not be able to determine the order of two values one of which has a
time zone and the other does not. The order relation on
time values is the
Order relation on dateTime (§3.2.7.4) using an arbitrary date. See also
Adding durations to dateTimes (§E). Pairs of time values with or without time zone indicators are totally ordered.
Note: See the conformance note in
(§3.2.6) which
applies to the seconds part of this datatype as well.
3.2.8.1 Lexical representation
The lexical representation for time is the left
truncated lexical representation for dateTime:
hh:mm:ss.sss with optional following time zone indicator. For example,
to indicate 1:20 pm for Eastern Standard Time which is 5 hours behind
Coordinated Universal Time (UTC), one would write: 13:20:00-05:00. See also
ISO 8601 Date and Time Formats (§D).
3.2.8.2 Canonical representation
The canonical representation for time is defined
by prohibiting certain options from the
Lexical representation (§3.2.8.1). Specifically, either the time zone must
be omitted or, if present, the time zone must be Coordinated Universal
Time (UTC) indicated by a "Z".
Additionally, the canonical representation for midnight is 00:00:00.
