This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current (1.1) canonical forms for datetime and datetimeStamp meet requirements for one kind of use case, in which timezone distinctions are semantically significant. (In essence, with datetimeStamp, provenance information is being encoded into the literal form of the datetime representation in the timezoneFrag.) However, there are many use cases in which the timezone provenance is not needed. And in these use cases, variability in the timezoneFrag makes it unnecessarily difficult to compare datetimes for equality (or greater-than or less-than), because it forces the comparison function to be datatype aware instead of being able to perform a simple string comparison. In particular, an implementation is forced to parse apart the datetime components and perform datetime arithmetic to add in the timezone offset. These use cases could be addressed by defining an additional canonical form consisting of the datetimeStamp type in which the timezoneFrag is required to be "Z". Please note that I am not asking for the existing canonical form to be *changed* to meet this requirement. Those forms are important for other use cases. I am asking for an *additional* canonical form to be defined.
Surely it's easy enough to constrain the timezone to be Z by using a pattern or an assertion? (A pattern if you literally want "Z", an assertion if you are also prepared to accept "+00:00" as equivalent).
Yes, it would be easy enough to do. The point is to have a *standard* so that anyone or any other spec can point to it and all applications that use datetimes only to represent points in time can use the *same* literal format.
Well, I don't think there will be any opportunity any time in the next five years to add new types to the base specification, however strong the case. So I'd suggest you find some other vehicle for this "standard". I think people are going to have to get used to the idea that if a type can be defined using the primitives in the XSD spec, then it can be standardized elsewhere without a change to the core language.
As staff contact at W3C for XML Schema I'll note that the Schema Working Group is not able to take on new work right now. However, W3C does have Community Groups that anyone could join, so it's possibly a community coup could publish a draft, and conceivable the Schema Working Group could then publish that as a Working Group Note. See http://www.w3.org/community/ Liam (XML Activity Lead at W3C)