Timestamp parsing fails when fractions of seconds are supplied.


Today, I found this in our error log. It appears that some clients include fractions of seconds when creating a date/time instance.

http://xmpp.org/extensions/xep-0082.html is fine with this. Openfire should ignore the fraction instead of throwing this error.




Guus der Kinderen
April 17, 2015, 8:35 PM

Modified the parser to neglect all but the first three second-fragments.

Guus der Kinderen
March 27, 2015, 9:09 AM

Florian: jxmpp sounds like a good idea. Tinder was created with more-or-less the same idea - perhaps the two could be merged?

csh: the implementation removes the colon for processing (which is why it does not show up in the exception message) - the original input does actually contain it.

March 23, 2015, 11:53 AM

IMO, the main problem is not the fractions (nanoseconds), but the missing colon in the timezone, which is required by XEP-0082 (or generally by the XML dateTime type). So in this case, the client violated the spec.

If you omit the nanoseconds, but leave the timezone in a bad format, it still fails:

Nonetheless, XMPPDateTimeFormat still has a problem, when providing more than 3 digits for the nanoseconds, even if the timezone is correctly formatted.

Both of these work well:

Florian Schmaus
March 22, 2015, 10:21 AM

It may be worth considering adding jxmpp(-core) to Openfire and use its XmpDateTimeUtil, where I just recently fixed that exact issue. The idea of jxmpp is to avoid solving the same problems again and again in XMPP client, server and component implementations. One could argue that it's a problem that jxmpp's date/time util uses a single synchronized parser, but 1. I don't think that's an issue, even in XMPP server environments and 2. if it's really an issue, then this could be easily changed.



Guus der Kinderen


Guus der Kinderen