Actually... that date format doesn't work either. Java timezones are not
compatible with ISO8601 formats.
The is what I ended up doing (and it is uggggly):
private final static String[] ISO_8601_DATE_FORMATS =
new String[]
{
"yyyy-MM-dd'T'HH:mm:ss.SSSZ",
"yyyy-MM-dd'T'HH:mm:ss.SSS",
"yyyy-MM-dd'T'HH:mm:ssZ",
"yyyy-MM-dd'T'HH:mm:ss",
"yyyy-MM-dd",
};
String str = "2007-05-10T15:22:07.000Z"; // the time to translate
TimeZone tz = null; // fill this in with the time zone that
//non-timezone encoded times will use.
Date result = null;
// convert timezones from ISO 8601 notation
str = str.replaceAll("Z$", "+0000");
str = str.replaceAll("([\\+\\-]\\d\\d):(\\d\\d)$", "$1$2");
for (String format : ISO_8601_DATE_FORMATS)
{
try
{
SimpleDateFormat dateFormat = new SimpleDateFormat(format);
// add in the timezone if the format specifies it.
if (! format.endsWith("Z"))
{
dateFormat.setTimeZone(tz);
}
result = dateFormat.parse(str);
break;
}
catch (ParseException ex)
{
// do nothing
}
}
if (result == null)
{
throw new ParseException();
}
Cheers,
-aLEX
Walker, Jeff wrote:
> I think we all agreed many posts ago that it is best (if not elementary)
> to transfer dates via plain strings, defined in schema. It definitely
> doesn't cause you any integration issues since you take the date and
> simply build the appropriate object from it. (Surprisingly ugly, for
> Java).
>
> // Take a string and create a Calendar object from it
> Date requiredDate = null;
> String existingString = "2007-05-10T15:22:07.000Z"; // Get this from web
> service
> SimpleDateFormat sdf = new
> SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
> try {
> requiredDate = sdf.parse(formattedStr);
> }
> catch (java.text.ParseException pe) {
> System.out.println("We got a parsing exception: " +
> pe.getMessage());
> }
> Calendar newCal = new GregorianCalendar(TimeZone.getTimeZone("GMT"));
> newCal.setTime(requiredDate);
>
> You might need to pass the timezone as a separate string field, I think.
> Here I used "GMT" but you will pass it as a separate parameter in a web
> service call.
>
>
> Also, looking at Axis 1.3 src it builds a SimpleDateFornmat object from
> the GMT timezone. There is no way to change that unless you edit the
> org.apache.axis.encoding.ser.CalendarSerializer class and then recompile
> Axis. Yuk.
> -jeff
>
>
>
>
>
>
>
> -----Original Message-----
> From: Ford, Jennifer M. [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 05, 2007 4:05 PM
> To: [email protected]
> Subject: RE: axis Calendar time zones
>
> Unfortunately, I don't think that's possible. You'll just have to
> translate to/from GMT on each end.
>
> -----Original Message-----
> From: Simon Steinacker [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 05, 2007 2:57 PM
> To: [email protected]; [EMAIL PROTECTED]
> Subject: axis Calendar time zones
>
> Hello,
>
> I am currently using axis 1.3, working with java Calendar objects across
> Web Services.
> I realized, that axis by default sets the timezone to GMT when
> serializing dates.
>
> How can I tell axis which timezone it should use?
> Thanks a lot,
> Simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
