Re: DateTool not ISO8601 compliant
Jochen Wiedmann wrote: Daniel L. Rall wrote: Jochen, I defer to John on the timezone interpretation of what's generally accepted as output by common server implementations. However, like usual, I'm of the opinion that servers should be gracious about the types of input accepted, so long as doing so isn't explicitly against the specs (XML-RPC and ISO 8601 apply here), or overly complicates the code. Assuming your patches to parse time zone and to interpret millis follow these rules, send'em over. However, for the sake of interoperability with less forgiving servers, our client will not generate output of this less-common sort. I'll query [EMAIL PROTECTED], whether the DateFormat classes can be moved to some common jar file. Interesting -- what package does that date formatting code belong to now? If it's homeless, I wouldn't mind adding it to Jakarta Commons Lang. Use of a third-party JAR is reasonable for HEAD (2.0), which has more dependencies, but not ideal for 1.2 (or any 1.x release), which does not include much in the way of external dependencies. If so, I'll post a patch using the DateFormat from the jar file for reading. Otherwise, I'll post a patch using a copy of XsDateFormat. Ok? Excuse my ignorance, but what is XsDateFormat and from whither does it hale? - Dan
Re: DateTool not ISO8601 compliant
On Do, 2004-06-17 at 09:36, John Wilson wrote: The XML-RPC spec (http://www.xml-rpc.com/spec see the last but one bullet point) says that timezones may not be present in a date. The generally accepted interpretation of the spec is that only the precise subset of ISO 8601 date/times given in the spec are legal in an XML-RPC message. (Welcome to the wacky world of Dave winner's specs!) That still leaves the question of millis, IMO. Jochen
Re: DateTool not ISO8601 compliant
On 17 Jun 2004, at 09:20, Jochen Wiedmann wrote: On Do, 2004-06-17 at 09:36, John Wilson wrote: The XML-RPC spec (http://www.xml-rpc.com/spec see the last but one bullet point) says that timezones may not be present in a date. The generally accepted interpretation of the spec is that only the precise subset of ISO 8601 date/times given in the spec are legal in an XML-RPC message. (Welcome to the wacky world of Dave winner's specs!) That still leaves the question of millis, IMO. The example in the spec does not include milliseconds - the generally accepted interpretation of the spec (i.e. by XML-RPC implementers) is that they are not permitted. John Wilson The Wilson Partnership http://www.wilson.co.uk
Re: DateTool not ISO8601 compliant
On Do, 2004-06-17 at 10:24, John Wilson wrote: The example in the spec does not include milliseconds - the generally accepted interpretation of the spec (i.e. by XML-RPC implementers) is that they are not permitted. If so, that leaves still more room for vendor extensions ... :-)
Re: DateTool not ISO8601 compliant
On 17 Jun 2004, at 09:40, Jochen Wiedmann wrote: On Do, 2004-06-17 at 10:24, John Wilson wrote: The example in the spec does not include milliseconds - the generally accepted interpretation of the spec (i.e. by XML-RPC implementers) is that they are not permitted. If so, that leaves still more room for vendor extensions ... :-) The strengths of XML-RPC are its simplicity and interoperability with a very wide range of other implementations. The creator of the spec and the person who claims ownership of the XMl-RPC trademark has repeatedly and vociferously stated that 'vendor extensions' are unacceptable because of the impact on interoperability. I very rarely agree with Dave Winer but I do see his point on this. I would most strongly oppose any introductions of 'vendor extensions' of this sort to the Apache XML-RPC implementation. John Wilson The Wilson Partnership http://www.wilson.co.uk
