[
https://issues.apache.org/jira/browse/CXF-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16166314#comment-16166314
]
Daniel Kulp commented on CXF-7502:
----------------------------------
I believe this issue is entirely caused by the java date handling stuff. The
java.util.Date object you are using for the webservice is likely a Julian date
representation of what is passed in. Internally to JAXB, it creates an
javax.xml.datatype.XMLGregorianCalendar and then has to use that to create the
Date object. I'm not sure if it adjusts that Date object to Julian or not.
When writing out the Date, it does the reverse to create the
XMLGregorianCalendar object that is written out. At that point, I don't
believe JAXB would have any idea if the incoming Date is Julian or Gregorian
and thus likely assumes it's Julian based on the "age".
The best option to avoid the confusion is to change the web service to use
javax.xml.datatype.XMLGregorianCalendar instead of java.util.Date. By keeping
it in Gregorian, the strange conversions should be avoided. Note: when
generating code from wsdl, the tools map xsd:date to XMLGregorianCalendar. In
any case, I'd avoid using java.util.Date.
> Invalid or wrong dates returned
> -------------------------------
>
> Key: CXF-7502
> URL: https://issues.apache.org/jira/browse/CXF-7502
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.1.12
> Environment: 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
> Reporter: Noxx
>
> 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):
> {code:none}
> import datetime
> data = datetime.date(1500, 3, 9)
> end = datetime.date(1500, 3, 12)
> with open("dateplotter.txt", "w") as file:
> while data <= end:
> returned = <soap_client>.date(data)
> if returned:
> returned = returned.date()
> file.write("{} results in {}, diff: {}\n".format(data, returned,
> (returned-data).days))
> else:
> file.write("{} results in {}, diff: {}\n".format(data, returned,
> "--ERROR--"))
> file.flush()
> data = data + date
> {code}
> On the server side the incoming date object is returned without modification:
> {code:java}
> @WebMethod(action = "date")
> public Date date(@WebParam(name="date") Date date) { return date; }
> {code}
> The content of the created file:
> {code}
> 1500-03-09 results in 1500-02-28, diff: -9
> 1500-03-10 results in None, diff: --ERROR--
> 1500-03-11 results in 1500-03-01, diff: -10
> 1500-03-12 results in 1500-03-02, diff: -10
> {code}
> The request/response for the first roundtrip:
> {code}
> ==>
> http_headers: {'SOAPAction': '"date"', 'Content-Type': 'text/xml;
> charset=utf-8'}
> operation: date(date: xsd:dateTime) -> return: xsd:dateTime
> binding_options: {'address': 'https://mio/StepServer/service'}
> <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/";>
> <soap-env:Body>
> <ns0:date xmlns:ns0="http://step";>
> <date>1500-03-10T00:00:00</date>
> </ns0:date>
> </soap-env:Body>
> </soap-env:Envelope>
> ==>
> <==
> http_headers: {'Keep-Alive': 'timeout=5, max=89', 'Content-Encoding': 'gzip',
> 'Connection': 'Keep-Alive', 'Content-Type': 'text/xml;charset=UTF-8',
> 'Server': 'Apache/2.4.18 (Ubuntu)', 'Date': 'Wed, 13 Sep 2017 08:52:55 GMT',
> 'Content-Length': '159', 'Vary': 'Accept-Encoding'}
> operation: date(date: xsd:dateTime) -> return: xsd:dateTime
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> <soap:Body>
> <ns1:dateResponse xmlns:ns1="http://step";>
> <return xmlns:ns2="http://step";>1500-02-28T00:00:00+01:00</return>
> </ns1:dateResponse>
> </soap:Body>
> </soap:Envelope>
> <==
> {code}
> The request/response for the second roundtrip which results in an hard error
> on the client side:
> {code}
> ==>
> http_headers: {'SOAPAction': '"date"', 'Content-Type': 'text/xml;
> charset=utf-8'}
> binding_options: {'address': 'https://mio/StepServer/service'}
> <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/";>
> <soap-env:Body>
> <ns0:date xmlns:ns0="http://step";>
> <date>1500-03-11T00:00:00</date>
> </ns0:date>
> </soap-env:Body>
> </soap-env:Envelope>
> ==>
> <==
> http_headers: {'Keep-Alive': 'timeout=5, max=88', 'Content-Encoding': 'gzip',
> 'Connection': 'Keep-Alive', 'Content-Type': 'text/xml;charset=UTF-8',
> 'Server': 'Apache/2.4.18 (Ubuntu)', 'Date': 'Wed, 13 Sep 2017 08:52:55 GMT',
> 'Content-Length': '159', 'Vary': 'Accept-Encoding'}
> operation: date(date: xsd:dateTime) -> return: xsd:dateTime
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> <soap:Body>
> <ns1:dateResponse xmlns:ns1="http://step";>
> <return xmlns:ns2="http://step";>1500-02-29T00:00:00+01:00</return>
> </ns1:dateResponse>
> </soap:Body>
> </soap:Envelope>
> <==
> [2017-09-13 10:52:55,425][ ERROR][zeep.xsd.types.simple] Error during xml ->
> python translation
> Traceback (most recent call last):
> File "C:\Python34\lib\site-packages\zeep\xsd\types\simple.py", line 61, in
> parse_xmlelement
> operation: date(date: xsd:dateTime) -> return: xsd:dateTime
> return self.pythonvalue(xmlelement.text)
> File "C:\Python34\lib\site-packages\zeep\xsd\types\builtins.py", line 136,
> in pythonvalue
> return isodate.parse_datetime(value)
> File "C:\Python34\lib\site-packages\isodate\isodatetime.py", line 55, in
> parse_datetime
> tmpdate = parse_date(datestring)
> File "C:\Python34\lib\site-packages\isodate\isodates.py", line 193, in
> parse_date
> int(groups['month']) or 1, day)
> ValueError: day is out of range for month
> {code}
> Remarks are:
> * (!) 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)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
