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

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.

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:

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.