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
