You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Joe Plautz <jo...@customcall.com> on 2005/07/25 21:59:10 UTC
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
Re: DateTime
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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
jeff@cogentlogic.com 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" <dm...@sosnoski.com>
>To: <ax...@ws.apache.org>
>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
>>
>>
>>
>>jeff@cogentlogic.com 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" <jo...@customcall.com>
>>>To: <ax...@ws.apache.org>
>>>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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: DateTime
Posted by je...@cogentlogic.com.
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" <dm...@sosnoski.com>
To: <ax...@ws.apache.org>
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
>
>
>
> jeff@cogentlogic.com 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" <jo...@customcall.com>
> >To: <ax...@ws.apache.org>
> >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
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
Re: DateTime
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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
jeff@cogentlogic.com 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" <jo...@customcall.com>
>To: <ax...@ws.apache.org>
>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
>>
>>
>>
>>
>>
>>
>
>
>
Re: DateTime
Posted by Joe Plautz <jo...@customcall.com>.
Thanks for the incite it's been very helpful.
Let me explain the situation a little bit further because I'm not sure I
explained it well enough. It's our client and our server. The client
is PowerBuilder and the server is AXIS. PowerBuilder is not providing
the timezone information to AXIS and I'm pretty sure that PowerBuilder's
Web Service library probably doesn't support it. Would this possibly
cause the issues with daylight savings time? Because I would think that
AXIS would take care of this.
Joe
jeff@cogentlogic.com 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" <jo...@customcall.com>
> To: <ax...@ws.apache.org>
> 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
>>
>>
>>
>>
>
>
> .
>
Re: DateTime
Posted by je...@cogentlogic.com.
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" <jo...@customcall.com>
To: <ax...@ws.apache.org>
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
>
>
>
>
Re: DateTime
Posted by Anne Thomas Manes <at...@gmail.com>.
What's the "y" namespace? Is it the XML Schema namespace or an
application-specific namespace? Perhaps the data type is based on XML
Schema, but it might be different...
Anne
On 7/25/05, Joe Plautz <jo...@customcall.com> wrote:
> 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
>
>
>