[ 
http://issues.apache.org/jira/browse/AXIS-1399?page=comments#action_12357042 ] 

Simon Tuckwell commented on AXIS-1399:
--------------------------------------

Hopefully this issue is related!

There are de/serialisation problems with the AXISCPP v1.5 project in the file 
src/soap/xdl/DateTime.cpp.  It determines the current timezone offset by 
running tests using the fixed unix time 0, i.e. 01/01/1970 00:00:00.  In the 
U.K., we were on BST from 1968-1971 (see 
http://en.wikipedia.org/wiki/British_Summer_Time) which changes the result of 
the calculation for us.  The rest of the world doesn't see this problem.

On our systems, the error results in the offset being added once at 
serialisation and again at deserialisation, hence we see a two-hour offset.

I believe a better solution is to use the current time or the external variable 
timezone.


> axis.types.Time does not deserialise properly in UK/GMT0BST
> -----------------------------------------------------------
>
>          Key: AXIS-1399
>          URL: http://issues.apache.org/jira/browse/AXIS-1399
>      Project: Apache Axis
>         Type: Bug
>   Components: Deployment / Registries
>     Versions: current (nightly)
>  Environment: Java1.4.2 on RH9.0 and Windows XP2 SP2
>     Reporter: Steve Loughran

>
> The axis time class does not properly deserialise a time when running in the 
> UK (at least on both systems tested)
> TestDeser2001.testTimeZoneLogicWorks() demonstrates the problem
> The underlying cause appears to be in Time.ParseHoursMinutesSeconds(), where 
> zulu.parse() takes in a string like "12:30:00Z" and, in the UK, returns a 
> timestamp bound to 13:30:00. 
> This is quite a serious difference in expectations, and appears to be 
> happening somewhere we cannot get at. Either it is a TZ issue, a locale 
> issue, a bug in Java1.4.2, or an installation defect common to two systems 
> (and platforms) under my control. 
> I dont have an obvious fix, but I would hesitate to ship with such a deser 
> bug, were time not such a troublespot already. 
> I think the ideal solution may be to abandon the built in simple time parser 
> completely and do it ourselves, the way we do partially anyway, then write 
> some good tests for the new code. Too bad we cannot use java1.4 regexp (or C 
> sscanf()) to do the low-level work.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to