[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] the "NotOnOrAfter" issue
> dateTime allows arbitrary sub-second precision and arbitrary > timezones > expressed as hh:mm offsets from UTC. > > > I suggest subclassing xsd:dateTime to: disallow fractional > seconds and > timezones other than UTC. > Rich, I think we just cross-posted on this, so let me ask you this: Since dateTime does uniquely identify a time what is the value of requiring dateTime to be expressed in strict UTC? It seems to me that the only benefit here is that SAML-processors need a little less code (i.e. the code that transforms a local+UTC offset into UTC). That argument strikes me as pretty soft, since it seems to me that the majority of systems won't be coding from a scratch--they'll be built on top of some level of Schema-aware libraries that should handle this. I do agree with Stephen that we need to make some explicit statement about fractional seconds, but I don't think we need to disallow them. Adding a note to the effect that all unreported sub-second precision digits in a given time are zero, with the standard time comparison rules in effect, should handle any ambiguities without removing any potential utility in fractional second precision. C.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC