Skip navigation
1397 Views 4 Replies Latest reply: May 7, 2012 12:29 PM by ctread RSS
ctread Bronze 3 posts since
May 7, 2012
Currently Being Moderated

May 7, 2012 8:44 AM

Smack 3.2.x with XCP 5.8 DelayedInformation always shows current time

I'm using Smack 3.2.1 to communicate with Cisco (formerly Jabber) XCP 5.8. It works pretty well but XCP 5.8 returns delayed delivery timestamps using an older format that is similar to, but not exactly, what Smack is looking for. The result is that when a user joins a MUC room all messages have the current time as their timestamp regardless of when the message was actually sent.


XEP-0091 ( says the timestamp should look like this: CCYYMMDDThh:mm:ss.

XCP 5.8 returns a stamp that looks like this: CCYYMMDDThh:mm:ss.millis (e.g., 20120507T12:13:14.123456). Note the inclusion of a millisecond component to the timestamp.


Anyway, this was causing Smack to miss the originally sent stamps XCP was setting which resulted in the provider defaulting to the current time. I created a custom build for us to use that modifies line 75 from this:


formats.put("^\\d+T\\d+:\\d+:\\d+$", DelayInformation.XEP_0091_UTC_FORMAT);


to this:


formats.put("^\\d+T\\d+:\\d+:\\d+(\\.\\d+)?$", DelayInformation.XEP_0091_UTC_FORMAT);


I realize this isn't 100% in compliance with what XEP-0091 specifies (though it does align with XEP-0082 in terms of optional millis), so it might be better to define another format rather than tacking it onto the XEP-0091 format regex.


Regardless, I think this would be helpful if this were included in a future release.

  • rcollier KeyContributor 982 posts since
    Mar 4, 2009

    Even XEP-0091 is marked obsolete, so I don't see any point in modifying the code to handle a custom use case for an obsolete spec.


    I suggest you simply write your own provider to handle the extension though, instead of creating a custom build.  Then you just need to replace the default provider with your own.

More Like This

  • Retrieving data ...

Bookmarked By (0)