axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Dick <>
Subject RE: Fw: Re: FIXED: RE: Carston: please help
Date Fri, 15 Jul 2005 15:32:59 GMT

I've now fixed the MockServer to be able to handle working in timezones
other than GMT/UTC - for xsd:dateTime and xsd:time.
When creating the server responses for unittests, provide the expected
(local) time in the response file and append ##TIME## instead of any
timezone offsets (or Z).

For xsd:time (see also response for XSD_time)
For xsd:dateTime: (see also response for XSD_dateTime)

As for being able to take absolute (GMT/UTC), we may wish to provide this
extra function at some point (perhaps capture this as JIRA now), but I have
done some testing with Axis Java, and our current mode of operation is
consistent with their behaviour.
The fix for AXISCPP-291 (
) may provide a neat structure into which thiscapability could be included.

Adrian Dick (

"Carsten Blecken" <> wrote on 11/07/2005 16:02:57:

> One thing we could do is to allow the xsd:dateTime
> desrialization to be in absolut (GMT/UTC) time.
> Since the current local time deserialization is still
> necessary, this would need to be configurable -
> one more item to axsicpp.conf for example.
> This would be not just for the unit tests but we
> have a customer who wants to have GMT/UTC times
> and has to jump through hoops right now with the
> fixed local time conversion of xsd:dateTime. I think
> this would be quite useful to add.
> Carsten
> -----Original Message-----
> From: Adrian Dick []
> Sent: Monday, July 11, 2005 1:02 AM
> To: Apache AXIS C Developers List
> Subject: RE: Fw: Re: FIXED: RE: Carston: please help
> "Carsten Blecken" <> wrote on 09/07/2005
> > (it took me a
> > while to realize that the checked-in expected file contain
> > times 8 hours before my timezone - how does developers unit
> >  test who are not in GMT+00 ?).
> Hmm ... yeah, I've been wondering about this, either we need to "smart"
> the framework to cope with this, or perhaps our general approach to
> date/time isn't quite right?
> Adrian

View raw message