At 11:54 PM -0700 6/29/04, Daniel L. Rall wrote:
+1 on committing this patch to CVS HEAD (only).
Steve, this is quite a bit of code. Any chance of a JUnit test case
to go along with it? It's the perfect sort of code for a unit test.
Attached.
Note that dates without time zone information is in a
At 9:00 AM +0200 6/30/04, Jochen Wiedmann wrote:
Daniel L. Rall wrote:
+1 on committing this patch to CVS HEAD (only).
Why not better using the XsDateTimeFormat from ws-jaxme?
I'll be the first to admit this is probably not the best solution, as
a matter of fact, I noted this in the comment I sent
At 11:54 PM -0700 6/29/04, Daniel L. Rall wrote:
+1 on committing this patch to CVS HEAD (only).
Steve, this is quite a bit of code. Any chance of a JUnit test case
to go along with it? It's the perfect sort of code for a unit test.
Steve Quint wrote:
The current DateTool can only deal with one
Daniel L. Rall wrote:
+1 on committing this patch to CVS HEAD (only).
Why not better using the XsDateTimeFormat from ws-jaxme?
+1 on committing this patch to CVS HEAD (only).
Steve, this is quite a bit of code. Any chance of a JUnit test case to go
along with it? It's the perfect sort of code for a unit test.
Steve Quint wrote:
The current DateTool can only deal with one form of ISO 8601 dates - one that look like
"yy
The current DateTool can only deal with one form of ISO 8601 dates - one that look
like "MMddThh:mm:ss". Any time zone information is discarded by the
SimpleDateFormat object due to the format string. Even worse, any other variant of
ISO 8601 will cause the entire XMLRPC transaction to fai
