[jira] Commented: (AXIS-1399) axis.types.Time does not deserialise properly in UK/GMT0BST

["Simon Tuckwell (JIRA)" <ax...@ws.apache.org>]

    [ 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