-Original Message-
From: WeBMartians [EMAIL PROTECTED]
Can the standard state that datetime strings support ISO 8601:2004 and leave
it at that? (just a thought)
Considering the considerable number of formats that ISO 8601:2004 encompasses,
I don't think that would be a good idea. The following format possibilities
for specifying instants in time, while acceptable to ISO 8601:2004 would not be
worth adding to HTML 5 under any use case I can imagine.
I really can't see why they bothered with the century format except as
supplemental field for pre Y2J applications that used a 2 digit year field.
Decimal minutes and hours are allowed in ISO 8601:2004, but lead to problems
with rounding once one gets to increments smaller than 0.0001 min and 0.1 h
respectively, so should probably not be adopted.
The alternate ways of representing 1985-04-12: the ordinal date (1985-102) and
the week date (1985-W15-5) don't offer anything that would justify the extra
complexity that would be required of the parser.
In case the specification ever develops a use case for a comma separated list
of datetime values, then the use of comma as an alternate to the period for the
decimal point should not be allowed.
HTML 4 currently allows only:
-##-##T##:##:##Z
-##-##T##:##:##+##:##
-##-##T##:##:##-##:##
These three formats are a subset of those suggested by the W3C datetime note
[1] which itself is a subset of the choices available under ISO 8601.
The HTML 5 draft currently extends this to allow:
* leaving out the seconds (valid under the W3C datetime note)
* adding a decimal point and one or more digits for fractional seconds (valid
under the W3C datetime note)
* specifying just the date (valid under the W3C datetime note)
* specifying just the time (valid under ISO 8601, but not the W3C datetime
note)
* replacing the T separator between the time and date with whitespace (NOT
VALID under ISO 8601)
* including some optional whitespace in some specific places (NOT VALID under
ISO 8601)
Unless allowing the whitespace is needed to back standardize an existing
implementation's handling of ins/del, it should be removed from the draft
as it is not ISO 8601 compliant and complicates the job of the parser, though I
grant it does improve the human readability slightly.
As a side issue, unless attribute values are restricted to ISO/IEC 656
characters, ISO 8601 appears to call for also accepting U+2010 HYPHEN as a
separator between the fields of a date value, and U+2212 MINUS for the sign in
a time zone designator or extended year representation.
The following is a list of steps for a parser that accepts a wide range of
valid ISO 8601 datetime formats, assuming that extended years are of the format
±Y and that at most 3 digits are allowed after the FULL STOP in the
seconds. Variables date, time, and zone are booleans for whether a date,
time, or timezone was present in the designation. Variables year, month,
day, hour, minute, second, millisecond, zonehour, and zoneminute
contain the correct results, but range checking for nonsense values as
2007-02-29 or even 2007-13-42 is not done, nor is converting them to value
stored in the DOM.
0. Set month and day to 1; set hour, minute, second, and
millisecond to 0; set date, time, and timezone to invalid; advance to
the first non-whitespace character.
1. If the next character is not PLUS, MINUS, or HYPHEN-MINUS, skip to step 5.
2. If the next character is not PLUS, set year to -1, else set year to 1.
3. Advance 1 character; if the next five characters are not in the set DIGIT
ZERO .. DIGIT NINE, abort as invalid.
4. Set date to valid; multiply year by the value given by the next five
characters; advance 5 characters; skip to step 7.
5. If the next four characters are not in the set DIGIT ZERO .. DIGIT NINE,
skip to step 17.
6. Set date to valid; set year to the value given by the next four
characters; advance 4 characters.
7. If the next character is whitespace, COMMA, or end of string, end as valid.
8. If the next character is not HYPHEN or HYPHEN-MINUS, abort as invalid.
9. If the next two characters are not in the set DIGIT ZERO .. DIGIT NINE,
abort as invalid.
10. Set month to the value given by the next two characters; advance 2
characters.
11. If the next character is whitespace, COMMA, or end of string, end as valid.
12. If the next character is not HYPHEN or HYPHEN-MINUS, abort as invalid.
13. If the next two characters are not in the set DIGIT ZERO .. DIGIT NINE,
abort as invalid.
14. Set day to the value given by the next two characters; advance 2
characters.
15. If the next character is whitespace, COMMA, or end of string, end as valid.
16. If the next character is not LATIN CAPITAL LETTER T abort as invalid.
17. If the next two characters are not in the set DIGIT ZERO .. DIGIT NINE,
abort as invalid.
18. Set time to valid; set hour to the value given by the next two
characters; advance 2 characters.
