> > The iCalendar date-time format is restricted to exactly one > > representation of date-time (not optional spaces, dashes, ...). > > There was a large debate on this before rfc2445 came out. > > We decided on ONE format for date time based on ISO-8601 > > > > YYYYMMDDTHHMMSS [+/- ...] > > > > If the intent is to be human readable - both loose. > > If the intent is to be machine readable - why another > similar format? > > One possible issue involves incompatibility with standard > formats defined by > other organizations, such as the W3C. XML Schema (for > example) defines a > date-time format [1] per ISO-8601's extended form; the shorter format > described in RFC2445 and ISO-8601 is invalid per XML Schema. > If the IETF > were to "require" RFC2445-compliant date-time values in > protocols we'd be > imposing a format that restricts use of XML Schema (and who > knows what else) > in protocol design. The formats specified in this new > document provide some > flexibility that may be useful in varied date-time > specification contexts. >
The W3C Schema work just ignored the previously published IETF iCalendar work effort. The issue is not that iCalendar is different than this yet-to-be-proven XML Schema data type for date time, but rather that the W3C work ignored the recommendations of the "time lords" in the IETF. In addition, the XML Schema date/time data type includes a UTC offset. This mixes time zone specification with date/time data types. Such coupling was found to be inappropriate for a data type that is used for calendaring and scheduling applications or other date/time dependent applications. So, the RFC2445 isn't "invalid per XML schema". Rather the opposite is true.
