[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. /r$ -- 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