This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In email to the XML Schema comments list on 5 September 2008 (http://lists.w3.org/Archives/Public/www-xml-schema-comments/2008JulSep/0135.html), Peter F. Patel-Schneider raised the following issue (among others): 1/ Time instants ... 1.2/ Handling "time instants" without a timezone There are already OWL ontologies that contain dateTime values where the timezone is absent. Such dateTime values may come from different documents, and that really have a different notion of what their local (unspecified) time is. The LC draft [2], however, makes these values all equal, as they are identical. The OWL WG is proceeding along a path to require timezones in dateTime values, i.e., dateTime values without a timezone will be syntactically illegal. However, tools may attempt to recover, for example by using the local time zone for the data source, but if they do so, they SHOULD produce a warning. Since such recovery may produce incorrect results, it should be done with caution, and data providers would be strongly encouraged to provide timezone information for all dateTime values. Adding in missing timezone values appears to violate the equality of dateTime values from the LC draft, as dateTime values without timezone information that compare equal according to the LC draft can be turned into dateTime values that do not compare equal. The WG requests that dateTime values missing a timezone that are otherwise equal do not compare as equal. The WG requests that dateTime values missing a timezone be instead *independently* treated as if they had one of the possible timezone values.
Thank you for the comment. Speaking for myself, I see your argument, and agree that at least in a wide variety of applications it is persuasive. (I think that some applications which omit time zone offset information do so because the offset is understood, or at least consistent. [All stores in this chain will open at 7 a.m. local time, and close at 11 p.m. local time. It is convenient to have a sanity check to ensure that closing time is later than opening time -- at least for businesses that do not stay open past midnight.] Such applications might find it painful to lose comparability among values without time zone offsets.) But I wonder; I think changing the definition of equality for so many values in the value space of this type could cause serious compatibility issues for users of XSD 1.0. If you can suggest any ways of mitigating those compatibility issues, please do so; otherwise, I'm afraid that the weight of the existing implementations of XSD, XPath 2.0, XSLT 2.0, and XQuery 1.0 are likely to make it impossible for the WG to follow the suggestion you make here. Would it be possible to define the indeterminacy of comparison at the OWL level, overlaying the XSD comparison by effectively defining an alternative partial ordering of the values?
OWL will probably proceed by suggesting that tools that see dateTime values without timezones "repair" the values by inserting some notion of the "current" timezone. I suppose that this is enough of a hack that it could fall outside the purview of the XML Schema WG. For example, the behaviour could be something like RDF document 1: ex:event ex:start-time "2007-09-10T15:00:00"^^xsd:dateTime RDF document 2: ex:event ex:end-time "2007-09-10T15:00:00"^^xsd:dateTime But an OWL processor could end up determining that the duration of ex:event was one hour (perhaps because the first document was produced by someone in the EDT timezone and the second by someone in the CDT timezone). The totality of the behaviour appears to violate the semantics of xsd:dateTime, and it would be nice to have some cover, perhaps only informative.
>OWL will probably proceed by suggesting that tools that see dateTime values without timezones "repair" the values by inserting some notion of the "current" timezone. That is of course exactly what XSLT and XQuery do, and if you are not familiar with how those specs handle timezone in date/time operations, then I would strongly suggest reading up on it, since (a) a lot of thought went into it, and (b) however imperfect, it will set the expectations of many of your users.
Is there a good pointer to the appropriate bit of the XSLT and XQuery specs?
I accepted an action to let the OWL WG know of our dispensation on this bug, but I'm slow to do so, since the response takes a great deal of care. Essentially Michael Kay is correct -- the short answer is that in many cases applications (in this case F&O for XQuery/XPath) provide some of the required semantics, and it will be difficult for XML Schema alone to give a satisfactory answer. Please stay tuned.
It has been suggested that the following line of reasoning, first formulated in private email, might be helpful to those trying to understand this problem report, and the XML Schema WG's response to it; I am posting it in case it is in fact useful in that way. The following paragraphs first attempt to provide a rationale for the original comment, and the final part proposes a response explaining why DESPITE the plausibility of the problem report, the right thing may be for the XML Schema WG to do nothing. ......... Let me see if I can put it in a nutshell: three steps to a conclusion. (1) XSD 1.1 says that if we compare 2008-07-14T10:01:42 and 2008-07-14T10:01:42+04:00 because one of them is the value of an upper or lower bound, and the other is the value in the instance, then (a) the two values are incomparable, and (b) the instance is not valid (because it doesn't provably satisfy the constraint). Rationale: the untimezoned value might correspond to any of the following values with timezones: 2008-07-14T10:01:42+04:00 2008-07-14T10:01:42+05:00 2008-07-14T10:01:42+03:00 and so we can't really tell whether it's REALLY less than or greater than the value of the upper or lower bound. (2) XSD 1.1 says that if we compare 2008-07-14T10:01:42 and 2008-07-14T10:01:42 then they are identical and equal. Rationale: they specify the same date, they specify the same time of day, neither of them has a timezone: they are the same value, and thus both identical and equal. (3) The rationales given in (1) and (2) have the spec talking out of both sides of its mouth. The rationale for making the first pair of values incomparable is that the untimezoned value might REALLY be any of the 1680 different values corresponding to that lexical form plus a time zone, and it applies equally well to the values in (2): either of them might REALLY be any of 1680 possible timezoned values, and so they really ought to be incomparable. So non-timezoned values ought to be identical to themselves, but not equal to themselves, just like NaN. ... Counter-argument: the rationale given in (1) is one way to look at things, but not the only way. Another way to think of it is that 2008-07-14T10:01:42+04:00 corresponds to a single point on the UTC timeline, and 2008-07-14T10:01:42 corresponds to a set of 1680 points on the non-timezoned timeline. Our ordering is defined in such a way that a singleton set is greater than another set iff the singleton value is greater than each individual value in the other set, and conversely for less-than.
I think there's another very pragmatic rationale as well. If two identical dateTimes without timezones weren't equal, then the same would logically have to be true for dates. And then you wouldn't be able to have a simple xs:date attribute with an enumeration such as 2008-01-31 2008-02-29 2008-03-31 2008-04-30 etc which would not only introduce a backwards incompatibility, it would also remove a useful facility with no justification outside the realms of abstract metaphysics. Michael Kay (personal response)
Completed action: ACTION 2008-11-14.01: DE to Send approved email wrt bug 6044 [recorded in http://www.w3.org/2008/11/14-xmlschema-minutes.html#action01] Sent http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2008Nov/0019.html