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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: Re: [security-services] the "NotOnOrAfter" issue

> Since dateTime does uniquely identify a time what is the value of
> requiring dateTime to be expressed in strict UTC?

There are some amazing subtleties, so that getting the math right can be 
tricky; remember that you *subtract* the offset, so you have to 
"borrow", so things like 2am on March 1, 2000 in Boston (EST5EDT) can be 
hard. If you do the "obvious" thing -- parse the time into something 
like the Unix time_t, number of seconds since an epoch -- you lose out 
because of leap-seconds; they get lost.  Now I, personally, don't care 
about leap seconds, but if I were writing a high-value financial system 
I would be very concerned if my infrastructure vendor wasn't aware of 
thsoe kinds of things.

As for sub-seconds, it's an issue of clarity -- folks are used to 
rounding, not truncation; what should 1.5 - .5 be?  What about 1.6 - .9? 
  etc? I think truncation is the only safe answer, otherwise you have to 
worry about XML Schema implementation errors when doing 
valuespace/lexical-space conversions of entries like 
2.999999999999999999999 seconds.  But as I said, folks are used to rounding.

Remember, if it's subclasses, it CAN Be treatred as a dateTime, so it's 
no extra work.  It's just a matter of enforcing the semantics in the 
contract definition, which is a good thing.

Zolera Systems, http://www.zolera.com
Information Integrity, XML Security

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

Powered by eList eXpress LLC