Resolution: Not A Problem
Server on Linux/Ubuntu 16.04 with Tomcat 8.5.12 and CXF 3.1.12
Client on Windows 7 64bit with Python3.4 and Zeep 2.2.0
I believe that the following is a CXF bug but as I am not really into the framework any help to isolate it or to report it to the correct tracker is really appreciated.
I am using the Python package "zeep" to generate a SOAP request, send it to my server and parse the response.
While handling dates within my application I came across the following issue and tried to reproduce it on an example:
Generate request on client side (you need to replace `<soap_client>` with your instance):
On the server side the incoming date object is returned without modification:
The content of the created file:
The request/response for the first roundtrip:
The request/response for the second roundtrip which results in an hard error on the client side:
- The date is already changed when accessing it on the server side within the method so sth. happens already when parsing the incoming stream.
- The difference between the date sent to the server and the date which the client gets back is changing dependent of the date sent.
A hard error occurs for a (non-existent) leap day.(see first comment)
- Within further tests I can reproduce:
- 1900-2100 the differences are 0 and no error occurs
- Dates near year 1 have a difference of 2 days (like 01.12.0001)
It seems there are two issues involved here:
Handling leap years seems to be incorrect as 1500 is not a leap year and 29.02.1500 does not exist but is returned as a date.(see first comment)
- As no conversation or other handling of the incoming date is performed on the server side - why it has been changed? In the example above I would expect to get the same date back as I sent to the server independent of the value (except for invalid dates like the not-existing leap-day)