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 email.
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
2005-02-04T17:20:00
?
-> 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
