[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: "solution" to Work Item 23
[I'm sorry this is so late, but it had dependencies on other people, and I wanted to make sure that we got it right...] Wayyy back, Steve Hanna and I found some problems with how XACML deals with time, date, and dateTime. Specifically, the problems involve time zones [1], implicit assignment of time zones, and ordering. At the time, we proposed two items that together should fix the problems: use XQuery functions for all equality and comparison checking, and define a new time-in-range function for determining if one time falls between two others. The second solution is already in the spec, and does solve a very real use case. The first item, however, required a little more thought. XQuery defines equality and comparison functions for date, time, and dateTime. XACML is currently using the equality functions, but not the comparison functions. For comparison, we're currently using XMLSchema, which doesn't define specific functions but does define ordering. Of course, when a timezone is only included in one of the two parameters to a comparison function, the ordering is only partial, so some cases are decidable and others are indeterminate. This is probably the right behavior for time, especially with the addition of a time-in-range function, because trying to add timezones and normalizing the two parameters causes some wierd situations. For date and dateTime, which exist on an infinite timeline and not a 24-hour loop, it's another matter. For instance, if I say something like "is April 6th, 2004 before the current date" I expect to always get an answer. If the current date includes a timezone, however, this is a partially ordered question, and in some cases will be indeterminate. Should we expect users to include timezones on all dates? Of course not, since people don't think about dates having timezones. I raise this issue because, based on our previous thread about date/time/dateTime, I'm not sure that everyone knows how this works. In general, I know that I find this topic quite confusing :) So, here is what I think should happen: 1. The definitions for date-equal, time-equal, and dateTime-equal, as well as the date, time, and dateTime datatypes, should be left as-is. 2. The definitions for the 4 time comparison functions should be left as-is, but the following clarifying text should be added: "Note that it is an error to compare a time without a timezone to a time with a timezone, so if you need this kind of functionality, use the time-in-range function." From what I know of the new XMLSchema specification, this is the correct behavior. 3. The definitions for the 4 date comparison functions, and the 4 dateTime comparison functions, should change to refernce the cooresponding functions in XQuery ([XF] in our references section). This will do the right thing in regards to assigning timezones and will eliminate all indeterminate cases (so, in other words, it will provide the functionality that I think most people expect). I also think we should include the following clarifying text: "Note that for parameters without a timezone, an implicit timezone is assigned as defined in [XF]." You can still include explicit timezones if you want. What exactly does this gain us? For one thing, it makes our handling of date, time, and dateTime much clearer. For another, it does away with any indeterminate evaluation cases. I can't find any discussions in the past that suggested a preference for errors in all partially-ordered cases, but if I've missed that please point me in the right direction. Thoughts? seth [1] Yes, all three datatypes include timezones. I can't think of many use cases where a date would need a timezone, but all the specifications referenced support this.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]