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.