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.
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 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!
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.
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.