[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xsd:dateTime vs. RFC 3339
Norman Walsh wrote:
The 05 draft of the Atom format says:
3.3 Date Constructs
A Date construct is an element whose content MUST conform to the
date-time BNF rule in [RFC3339].
I'm actually using xsd:dateTime in the RELAX NG grammar and I went off
to look at RFC 3339 thinking I might write a regex to do that instead,
since that's what the spec says. Then I got to wondering just how similar
the two definitions actually are. In some private correspondence, Paul
Byron made the following observations:
1. RFC 3339 allows lower- and upper-case 'T' and 'Z', while
xsd:dateTime requires upper-case only. There is a note in sect 5.6
of RFC 3339 which says:
This date/time format may be used in some environments or
contexts that distinguish between the upper- and lower-case
letters 'A'-'Z' and 'a'-'z' (e.g. XML). Specifications that use
this format in such environments MAY further limit the date/time
syntax so that the letters 'T' and 'Z' used in the date/time
syntax must always be upper case. Applications that generate
this format SHOULD use upper case letters.
I don't see this as a problem. We can either allow both (default), or
explicitly restrict it.
2. RFC 3339 allows the replacement of the 'T' with a space which
xsd:dateTime does not. [Note: ISO 8601 doesn't either, hence RFC
3339 isn't actually a "profile of ISO 8601" as it claims].
As far as I can tell, ISO 8601 allows this.
3. RFC 3339 does not allow the hour 24 but xsd:dateTime does (in
xsd:dateTime [as in ISO 8601] 00 & 24 both represent midnight, but
24 means the end of one day while 00 means the start of the next)
That looks like a useful restriction to me...
4. RFC 3339 gives a different semantic to a timezone offset of -00:00 from
+00:00 and Z which xsd:dateTime (and to the best of my knowledge
ISO 8601) doesn't. Sect 4.3 of RFC 3339 reads:
If the time in UTC is known, but the offset to local time is
unknown, this can be represented with an offset of "-00:00". This
differs semantically from an offset of "Z" or "+00:00", which
imply that UTC is the preferred reference point for the specified
time. RFC2822 [IMAIL-UPDATE] describes a similar convention for
I'm not sure how this is relevant. All three representations (Z, +00:00,
-00:00) refer to the same instant in time.
He goes on to suggest that there may be other differences, but these
are the ones he noticed. That's enough for me: they are different.
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML Schema Part 2 than RFC 3339.
I propose that we change the spec to do so.
So what do you do with something like
-> Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we may
have to profile one of them. In which case I'd prefer to stick with RFC3339.
Best regards, Julian
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760