[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