I think we're in complete agreement. The problem isn't that schema/ISO
8601 is wrong or inadequate, but that people using XML try to turn the
time values into something they're not (such as a Calendar instance...).
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA 425.885.7197
[EMAIL PROTECTED] wrote:
Hi Dennis,
You raise a very important point and one that I have never had cause to
address. I suspect that many people think in terms of time zones even though
properly qualified ISO 8601 values are UTC values.
What you correctly identify as a deficiency from the point of view of time
zone support is nonetheless a strength of ISO 8601 from the point of view of
accurate time keeping. The fact that ISO 8601 values do not identify time
zones but identify UTC values (albeit with possible offsets) means that any
identified instant is unambiguous. Anyone wanting to translate such values
into a representation of that same instant, an earlier one or a later one,
in any particular different time zone, is able to do so without error, given
sufficient algorithmic dexterity!
Jeff
----- Original Message -----
From: "Dennis Sosnoski" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, July 25, 2005 5:30 PM
Subject: Re: DateTime
Jeff, this is not strictly accurate. Even though the XML Schema
documents (and even ISO 8601) describe the offset as a "time zone"
schema does not actually support time zones other than UTC/GMT. If you
use a Z at the end of a dateTime value you're giving GMT directly. If
you use a +04:30 or some offset of this type you're only giving an
offset from UTC for the particular value, not defining a time zone.
Schema specifies that the offset value is added/subtracted from the
stated time value to obtain the official UTC value.
How is that different from a time zone? Mainly just in that there's no
provision for time changes. If you take a schema dateTime value from a
document and add 6 months to it (leaving the time part the same), you've
got another UTC value. In most time zones the correct offset from UTC
will be different for that point in time than for the original value,
but schema doesn't care since all values are either UTC or indeterminant
time zone (where indeterminant time zone means UTC +/- 14 hours, giving
a 28 hour uncertainty in the time). If you interpret those offsets as
representing real time zones the original value might be interpreted as
EST while the second one would be CDT.
This has been the cause of endless confusion in SOAP web services, since
many of the implementors interpreted that offset as defining a real time
zone. It's particularly a problem with Java, since people tried to
convert schema dataTimes into Calendar instances with real time zones.
Add six months to a Calendar and you end up changing the corresponding
UTC by 6 months +/- one hour.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA 425.885.7197
[EMAIL PROTECTED] wrote:
Joe, XML Schema dateTimes follow ISO 8601 which supports time zones, if
specified.
In the case of:
<in2 s:type="y:dateTime">2006-01-01T05:00:00.000</in2>
there is no time zone specifies, hence the time zone is 'unknown'.
To specify GMT, i.e. Coordinated Universal Time, use:
<in2 s:type="y:dateTime">2006-01-01T05:00:00.000Z</in2>
If time zones are an issue for you then you need to consult the web
service
provider to determine what they are providing. If they are not specifying
a
time zone but are providing time-sensitive data then it is likely that
they
are using what is local time for the host server. You could try to
persuade
the provider to specify a time zone. Failing that, you will need to make
adjustments that take into consideration daylight-saving time, if
necessary.
To make things worse (for some people), the U.S. Government are currently
involved in moves to change the starting and finishing dates for
daylight-saving time (possibly with effect from this Fall). This is
likely
to have a knock-on effect in Canada but that too is complicated by the
fact
that daylight-saving issues are determined at the provincial rather than
the
federal level in Canada so synchronization with the U.S. may be partial!
Jeff Lawson
----- Original Message -----
From: "Joe Plautz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, July 25, 2005 3:59 PM
Subject: DateTime
Hello,
We're having some issues calling a web service with a datetime
attribute. We're getting a date from the that looks like this,
<in2 s:type="y:dateTime">2006-01-01T05:00:00.000</in2>
which is causing issues all over the place. What I want to know is, what
timezone does this default to? Will it be the default? Will it take into
account for day light savings, because that's where our issue is. Any
help will be appreciated.
Thanks
Joe Plautz
