> 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
