When I saw SPEC I see Date should be used not Calendar.
Using Calendar instead of Date broke link with existing XML-RPC implementations, including XML-RPC 1.2 and 2.0 so we should use Date. Also the format is : <dateTime.iso8601> date/time 19980717T14:08:55 Nothing like AAAA-MM-JJTHH:MM:SS+ZZ:ZZ (ex: 2005-11-21T00:00:00+01:00), which is the SOAP date encoding. My patch restore use of java.util.Date as previously and provide Calendar as an extension. I'll send it tomorrow here. Regards 2006/5/16, Jochen Wiedmann <[EMAIL PROTECTED]>:
John Wilson wrote: > By all means introduce an extension which allows this form but the > unextended implementation should conform to the standard. As for the last part: I do believe we all agree on that. Question is whether implicit support is acceptable, following the mantra "strict on the output, lazy on the input". Personally, I'd vote in favour of that. Henri, a suggested solution: I believe we do agree that support for java.util.Calendar as well as java.util.Date is easy when creating XML. However, we could possibly offer a solution for the parsing side too: The method ReflectiveXmlRpcHandler.execute() could check for instances of java.util.Calendar. If it detects such instances, then it could check whether the corresponding parameter should be java.util.Date and, if so, convert it. That way we should both be upwards compatible and be able to offer timezone support. Jochen
