ParseException in message delay stamp due to microseconds

Smack Smack Dev
1

Hi,

I’m using eJabberd as my xmpp server. For reasons not completely clear to me, it returns microseconds in the stamp property of the delay element. When this is parsed by the XMPPDateTime methods in smack, it passes the match test thanks to the pattern that satisfys DateFormatType.XEP_0082_TIME_MILLIS_ZONE_PROFILE.

Unfortunately, all of Java’s inbuilt DateFormat tools do not work with microseconds and produce a ParseException if you try.

According to XEP-0082, (http://xmpp.org/extensions/xep-0082.html#sect-idp267120) the fractional seconds can contain “any number of digits”. So, technically, the eJabberd implementation is not incorrect.

I suspect that the simplest option is to chop off all but three numbers after the decimal point and before the z. The affected method is on line 94 of XMPPDateTime, but you might want to perform the operation before then.

Thanks,

Phil

2

Unfortunately, all of Java’s inbuilt DateFormat tools do not work with microseconds and produce a ParseException if you try.

It might not be available on Android, but DatatypeConverter.parseDate(“1969-07-21T02:56:15.123456Z”) works for me without exception.

3

Was this on Android? Could you show us the stacktrace of the generated exception?

4

Thanks for the idea, but DatatypeConverter isn’t implemented in Android. Also, after some testing I found that it actually broke some tests. For example, if you try the code:

Calendar cal = DatatypeConverter.parseDateTime(“2014-09-16T15:14:13.123456+0000”);

That doesn’t work. So you have to make sure it’s not in that format.

It’s really frustrating; in this day and age we still don’t have built in parsers that just work!

Phil

5

No, this is in Java 1.7 at the moment. Stacktrace below. It crashes because it attempts to read the fourth digit in the microsecond stamp as a time zone identifier.

java.text.ParseException: Unparseable date: “2014-09-16T15:14:13.123456+0000”

at java.text.DateFormat.parse(DateFormat.java:357)

at org.jxmpp.util.XmppDateTime$DateFormatType.parse(XmppDateTime.java:103)

at org.jxmpp.util.XmppDateTime.parseXEP0082Date(XmppDateTime.java:159)

at org.jxmpp.util.XmppDateTime.parseDate(XmppDateTime.java:209)

at org.jxmpp.util.XmppDateTimeTest.testParseMicroseconds(XmppDateTimeTest.java:235 )

6

Phil Winder wrote:

No, this is in Java 1.7 at the moment. Stacktrace below. It crashes because it attempts to read the fourth digit in the microsecond stamp as a time zone identifier.

That’s strange, because your testcase (found in the PR) was successful when I run it without truncating the fractions of seconds. But anyway, since XEP-82 allows any number of digits for the fractions, we must truncate it. I’ve decided to truncate to milliseconds, since this seems to work on every platform.

Thanks for your contribution and the issue report.

Consider it fixed.

7

Calendar cal = DatatypeConverter.parseDateTime(“2014-09-16T15:14:13.123456+0000”);

That doesn’t work. So you have to make sure it’s not in that format.

Yes, it’s because the time zone is not conform to ISO 8601 (and neither to XEP-0082). It needs to be “+00:00”. Then it works.

8

You’re right, my mistake. Thanks for bringing it to my attention.

Phil