ebMS invalid timestamp handling

[Martin Kalén]

Greetings,
I am having two timestamp problems with interop-testing Hermes ebMS
and another ebXML product.

I am aware of the recent UTC dateTime-fixes made in Hermes, the
following post describes two problems using a Hermes downloaded after
June 06, 2007.

Problems:
1. Hermes sends ebMS ACK messages with a non-standard timezone part of
the timestamp (timezone info is not according to ebXML-specification,
see background below)

2. Bug in incoming ebMS time-to-live timestamp comparison (see last
part of this post)

Background on #1:
The recent fix for Hermes UTC timestamps uses the Java
SimpleDateFormat "Z"-pattern for timezone, which is unfortunately
incompatible with the ebXML specification for time zone refering to
the XML schema data-type "dateTime" specified here:
http://www.w3.org/TR/xmlschema-2/#dateTime

Snippets from the spec:
"dateTime consists of finite-length sequences of characters of the
form: '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)?
(zzzzzz)?"

"zzzzzz (if present) represents the timezone"

>From 3.2.7.3 Timezones
"The lexical representation of a timezone is a string of the form:
(('+' | '-') hh ':' mm) | 'Z'"

In Java the ':' character is missing between the "hh" and "mm" parts.
More details on the Java SimpleDateFormat vs XSD dateTime
incompatibility can be found here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4919632

Suggested solution:
1. Outgoing ACK: change the Hermes ebMS usage of DataFormatter and
implement methods there to produce dateTime timestamps according to eg
http://www.dpawson.co.uk/relaxng/schema/datetime.html#d674e136

2. Parsing incoming timezone info correctly: the ebMS class
EbmsUtility has a bug in parsing incoming dateTime with the 'Z' only.
This should be regarded as a dateTime in the UTC timezone, but
EbmsUtility will place it in the JRE default timezone ie. the user's
local timezone. Change the following code EbmsUtility, line 66-69:
if (tzStr.length() == 1) // Case Z
tz = TimeZone.getDefault();
else
tz = TimeZone.getTimeZone("GMT" + tzStr);

to:
if (tzStr.length() == 1) // Case Z
tz = TimeZone.getTimeZone("UTC");
else
tz = TimeZone.getTimeZone("GMT" + tzStr);

Note the timezone for 'Z' changing from nothing to "UTC" on line 67.

I live in the UTC+02:00 timezone and today at 14:01 my time (=12:01
UTC time) an incoming ebXML message with the following TTL timestamp
was considered expired by Hermes: "2007-07-10T12:04:14Z".

Without the change in EbmsUtility above, Hermes regards the incoming
timestamp as 12:04 in my timezone which mutates the expected
12:04:14UTC to 10:04:14UTC = incorrect expiry notification to the
sender.

Any thoughts on this?

I would be happy to help with a patch also for issue #1 if you wish.

Best regards,
Martin

[Ronnie Kwok]

Hello Martin,

Thank you for your post and I agree these are issues that need to be
taken care. We are now digesting the information for issue #1, which
might need to bring up some discussion for the resolution.

For issue #2, we will work on the fix as suggested.

FYI, we are setting up the infrastructure for checking out our source
and submit changes. But there are some technical difficulties and I
hope it can be rectified soon.

Regards,
Ronnie

P.S. Much appreciated for the information you provided, it helps a lot
to us in understanding the issue and coming up the resolution.

> implement methods there to produce dateTime timestamps according to eghttp://www.dpawson.co.uk/relaxng/schema/datetime.html#d674e136

[Martin Kalén]

Hi Ronnie,
thanks for such a fast response!

On 11 Juli, 04:30, Ronnie Kwok <paperd...@gmail.com> wrote:
> FYI, we are setting up the infrastructure for checking out our source
> and submit changes. But there are some technical difficulties and I
> hope it can be rectified soon.

That's really good news; this really helps submitting better patches
since they are then always created from the latest source version.

Regards,
Martin