This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://www.w3.org/International/2005/02/xpath-review.html Comment ID: 2
Since many whole days of WG time have been spent on trying to find the best possible solution to this problem, you're going to have to come up with much more solid evidence of the supposed bugs, and with an alternative way of tackling the problem, if you think that the spec can be improved in this area. Please try to make your comments more constructive. Michael Kay (personal response)
The XML Query WG and XSL WG considered this comment at our May F2F meeting. We must respectfully decline to remove the Implicit Time Zone. The XML Schema datatypes xs:date, xs:time, and xs:dateTime allow values both with and without timezones. As a consequence of this, XML Schema says that some values with timezone and some values without timezone are incomparable. Our WGs considered this issue and decided that we must be able to use values of these types in an order by clause, which requires us to have a full ordering for these values. We considered a number of alternatives: - disallow comparison of values with timezones to those without timezones - define pairs of subtypes that require a timezone and do not allow a timezone, respectively. Comparison would only be allowed on these subtypes. - infer Z if no timezone was specified - allow every comparison operator to specify a timezone that would be used for values without a timezone We decided on the use of an implicit timezone (part of the dynamic context) whose value is implementation-defined. A user who does not wish to use this feature can use of fn:adjust-dateTime-to-timezone, fn:adjust-date-to-timezone, or fn:adjust-time-to-timezone in their query to apply a specific timezone to their values before they are used in a comparison. Please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.
consensus of the i18n-core wg (telecon 6 July 2005): A problem remains: What do you do if have several documents, with several (implicit) timezones? We don't think that your solution is interoperable. We propose to have a joint call between the working groups on the topic. Please tell us a convinient time. Best regards, Felix Sasaki.
Of course it might be true that the author of one document using a zoneless time was thinking of GMT, while the author of another document using a zoneless time was thinking of EST. There's really not much we can do about that. The solution we have is not intended to be perfect, it's intended to be a pragmatic compromise, and as such, not much will be achieved by pointing out its deficiencies unless a better solution is put on the table.
(In reply to comment #4) [personal comment] > Of course it might be true that the author of one document using a zoneless time > was thinking of GMT, while the author of another document using a zoneless time > was thinking of EST. Trying to talk this problem away with 'might' doesn't help at all. As long as the world is round, different authors WILL assume different time zones, period. > There's really not much we can do about that. Of course, there is A LOT that can be done about it. Andrew Eisenberg in his comment #2 mentioned four solutions that the WG looked at; at least the first three of them significantly improve the situation. (Unfortunately, Andrew's comment does not indicate any of the reasons for why these solutions were rejected.) (The fourth solution in Andrew's comment #2 is more like syntactic sugar, moving the potential conversion from a function on one (or both) operands to a potential attribute of the operand, and thus does not address the problem.) Other solutions would include a mandatory parameter on the whole query defining the assumed time zone for dates/times without timezones (for any query that contained any date/time-related operations; assuming for the moment that it's possible to figure this out, which it may not, in which case the mandatory parameter would have to be there for all queries). > The solution > we have is not intended to be perfect, Thanks for admitting that. > it's intended to be a pragmatic compromise, A compromize between what and what? Of all the proposals, it looks like the worst solution to me, which a compromize never should be. > and as such, not much will be achieved by pointing out its > deficiencies unless a better solution is put on the table. Please see Andrew's comment #2, and above. Regards, Martin.
The reason why it is as it is has to do with the following: In order to be able to order or optimize filters that include comparisons on date/time values wit the help of indices you need to be able to have the values in a complete order (as Andrew explains). If you have several documents that contain values that have differently implied timezones, you should do one of two things: 1. Use the adjust-timezone functions for each document value based on the local timezone. 2. Lobby your implementation to provide a mapping to a timezone when storing the document (thus loosing the "absence" of the timezone). The reason that we imply exactly one timezone is that we need something that can be implemented without having too much implementation complexity. Note that implementations can and some will default to Z...
OK, let's looks at the four ideas that Andrew put on the table: We considered a number of alternatives: A- disallow comparison of values with timezones to those without timezones B- define pairs of subtypes that require a timezone and do not allow a timezone, respectively. Comparison would only be allowed on these subtypes. C- infer Z if no timezone was specified D- allow every comparison operator to specify a timezone that would be used for values without a timezone The main problem with A is that with many comparisons, one of the operands is current-date(). It doesn't seem reasonable that current-date() gt xs:date('2000-01-01') should be an error on the grounds that current-date() has a timezone and the other date doesn't. 99% of users would be amazed to discover that dates are allowed to have timezones anyway. Providing additional functions to return the current date/time without a timezone gets ridiculous. B would be nice if Schema had done it this way in the first place, but they didn't. We want queries to work with existing documents and schemas, we don't want everyone to have to redesign their data so they can query it. Yes, this is the solution we adopted with durations - but they are used far less frequently than dates and times. C is a subset of the solution we have adopted. We allow the implementation to determine what the implicit timezone should be, and Z is one of the options. An implementation is even allowed to use Z without giving the user the option to choose something different. As someone who happens to live in timezone Z for half the year, I would personally be quite happy using an implicit timezone of Z, but people from other parts of the world seem to have different preferences. There's no intrinsic reason to choose one timezone rather than any other as the implicit timezone, so it seems reasonable to allow implementations to make it configurable. D is just overly cumbersome. Again, given the example current-date() gt xs:date('2000-01-01') forcing users to tell us what timezone they had in mind is just plain unfriendly. So: please accept that this is a difficult problem with no obviously right answer. Many people can legitimately have different views on which of the imperfect solutions is least bad. We've done our best to find something that works, and it does work reasonably well for most use cases. Going back to my original remark that there is nothing we can do when authors of two different documents assume two different timezones, there is of course something we can do: we can encourage them to specify the timezone explicitly. If they do that, everything works fine. If they don't, they get what they deserve, which is a "roughly correct" ordering that's fine to a certain level of precision, of around one day - which as it happens is good enough for very many applications, since far more people use dates than use times. Michael Kay
(In reply to comment #7) > The reason why it is as it is has to do with the following: > > In order to be able to order or optimize filters that include comparisons on > date/time values wit the help of indices you need to be able to have the > values in a complete order (as Andrew explains). Acknowledged. There is more than one solution that allows this easily, and avoid the problems that we point out. > If you have several documents that contain values that have differently > implied timezones, you should do one of two things: Who is 'you'? This is the World Wide Web. Documents and data get passed around. Writing as if documents were used in small contexts, with tight control and knowledge, is completely out of data. > 1. Use the adjust-timezone functions for each document value based on the > local timezone. Fine, except that we have to help people to use them from the start, to make sure that there won't be any bad awakenings. > 2. Lobby your implementation to provide a mapping to a timezone when storing > the document (thus loosing the "absence" of the timezone). This may not be the right solution. There are cases where there is truely no timezone. > The reason that we imply exactly one timezone is that we need something that > can be implemented without having too much implementation complexity. That's fine. > Note that implementations can and some will default to Z... Great in some sense, but even worse in some other: The cases where it by chance 'just works' (whatever 'it' be) are more, but that only means that the surprising and unpredicted consequences may hit harder when they finally hit. Regards, Martin.
(In reply to comment #8) [reply split into two parts] > So: please accept that this is a difficult problem I think we agree on that. >with no obviously right > answer. Maybe no obviously right one, but clearly better and worse ones, and the current one is on the worse side, unfortunately. >Many people can legitimately have different views on which of the > imperfect solutions is least bad. We've done our best to find something that > works, and it does work reasonably well for most use cases. Well, except when data from different sources (from different parts of the world,...) get combined, or servers moved from one timezone to another, and so on. > Going back to my original remark that there is nothing we can do when authors of > two different documents assume two different timezones, there is of course > something we can do: we can encourage them to specify the timezone explicitly. The best way to encourage them would be to make sure they do it right from the start (either they only have timezoned data, or they have other info in their data, such as a location,...). Using different types is best in this regard. Using a Z default probably gets this done to quite some extent. > If they do that, everything works fine. If they don't, they get what they > deserve, which is a "roughly correct" ordering that's fine to a certain level of > precision, of around one day - which as it happens is good enough for very many > applications, since far more people use dates than use times. See separate comment re. dates. Regards, Martin.
>Maybe no obviously right one, but clearly better and worse ones, >and the current one is on the worse side, unfortunately. Saying that doesn't make it true. Please accept that other people can have opinions too. I try to treat your opinions with respect, please do the same for mine. Michael Kay
(In reply to comment #8) > OK, let's looks at the four ideas that Andrew put on the table: > The main problem with A is that with many comparisons, one of the operands is > current-date(). It doesn't seem reasonable that > > current-date() gt xs:date('2000-01-01') > > should be an error on the grounds that current-date() has a timezone and the > other date doesn't. 99% of users would be amazed to discover that dates are > allowed to have timezones anyway. Agreed. It really doesn't make much sense. During the XML Schema discussion, I proposed to have only a restricted set of (sub-)types, and I think I left out dates-with-timezones explicitly. >Providing additional functions to return the > current date/time without a timezone gets ridiculous. Well, no, having a function that returns the date with a timezone in the first time might be called ridiculus. The situation can easily be fixed: Have current-date() return the date without a timezone. That alone will take care of most of the problems. For those people who think that a date needs a timezone, something like current-date-with-timezone() can be added at low additional implementation cost, if considered necessary. > B would be nice if Schema had done it this way in the first place, but they > didn't. We want queries to work with existing documents and schemas, we don't > want everyone to have to redesign their data so they can query it. Yes, this is > the solution we adopted with durations - but they are used far less frequently > than dates and times. It would be extremely nice if you did the right thing, given that you acknowledge that it's the right thing. People who designed their applications carefully will already have made sure that they distinguish between timezoned and non-timezoned stuff. Those who haven't done that will have to do that sooner or later anyway, either on the schema level or on another (query or application,...). People who will find the new types will have an easier job designing there applications in a better (clearer, less buggy, more interoperable) way. > C is a subset of the solution we have adopted. We allow the implementation to > determine what the implicit timezone should be, and Z is one of the options. An > implementation is even allowed to use Z without giving the user the option to > choose something different. As someone who happens to live in timezone Z for > half the year, I would personally be quite happy using an implicit timezone of > Z, but people from other parts of the world seem to have different preferences. > There's no intrinsic reason to choose one timezone rather than any other as the > implicit timezone, so it seems reasonable to allow implementations to make it > configurable. What is it that lets you over and over forget that this is the World Wide Web Consortium, not the Local My Data Only Consortium? Of course there is no intrinsic reason to choose one time zone or another, but there are very strong reasons, and benefits, to choose a single timezone (as opposed to 'whatever the implementation or the setting happens to be). > D is just overly cumbersome. Again, given the example > > current-date() gt xs:date('2000-01-01') > > forcing users to tell us what timezone they had in mind is just plain unfriendly. For that specific case, I fully agree. But that can be easily fixed, and in general, it's better to make sure the users are aware of the problem than to let them stumble. Regards, Martin.
(In reply to comment #11) > >Maybe no obviously right one, but clearly better and worse ones, > >and the current one is on the worse side, unfortunately. > > Saying that doesn't make it true. Of course saying that alone doesn't make it true. But I hope I gave quite a bit of arguments showing why I believe this to be so. > Please accept that other people can have opinions too. No problem with that at all. I was just trying to express my own opinion. >I try to treat your opinions with respect, please do the same for > mine. I didn't intend to do anything different. If it may have appeared so, please accept my apologies. Regards, Martin.
A Wiki page has been started to create wording to be published as a W3C Note to address this issue. Please take a look at http://esw.w3.org/topic/i18nFAQTimeZone#preview and comment.
On Sept. 27, 2005, the Query and XSLT working groups agreed to resolve this comment by inserting into the XPath Functions and Operators specification a reference to the note on "Working with Times and Time Zones", composed by the I18N working group (see draft in http://esw.w3.org/topic/i18nFAQTimeZone#preview).