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 > >> > >> > >> > >> > >> > >> > > > > > > > >
