OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: timezones and UTC

I've had my name next to a task to post a clarification on this point 
for a while now. Sorry it's taken so long. The issue, as I recall, is 
whether all time values in a Request must be in UTC (we've already 
agreed that policies may use any representation, and do not need o 
specify timezones).

As I see it, there are two problems with constraining the requests. The 
first is fairly straight-forward. In XACML 2.0, we do not allow 
comparison of times with timezones and times without timezones. This is 
the right behavior, as I explained in my original email. If we require 
all incoming times to b qualified with a timezone and be normalized, 
this will make it impossible to use the current equality and comparison 
functions with time values that have no explicit timezone (a usecase we 
agreed is important). They will still be useful in the time-in-range 
function, but not elsewhere.

The second problem is more subtle. Dates actually have the option to 
specify timzones, we just don't usually use them. If we require UTC 
normalization, then we must do so for dates as well, which will cause 
other failures in our current comparison system, unless all policies 
explicitly provide timezones. Is that what we really want? That will 
look very strange to most people.

So, in short, I strongly reccomend that we do not require all times to 
be in UTC or explicitly tagged with a timezone. I think it's fine if we 
add a non-normative section that explains some of these issues, and 
even explain why it's typically a good idea to use timezones in all 
values, but requiring this is a mistake.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]