We're updating the issue view to help you get more done. 

Add support for XEP-0202: Entity Time



Acceptance Test - Entry



Daryl Herzmann
February 11, 2014, 1:57 PM

@csh We'll see what Guus thinks.

Florian Schmaus
February 11, 2014, 2:54 PM

I'd rather not discuss patches in the bug tracker, but since there is no associated forum post: The fact that legacy date format is obsolete doesn't mean that we shouldn't support it. There are IIRC still a few XEPs out there that require it.

Furthermore, I don't see how XMPPDateTimeFormat duplicates DatatypeConverter. If that would be true, you wouldn't needed to write the getUtcDate() utility method. What duplicates DatatypeConverter is util.FastDateFormat, and I may be worth to evaluate which ones performs better and should be used. Nevertheless, the requirement for a XMPP date/time formatter/parser utility class remains.

February 11, 2014, 3:53 PM

getUtcDate() is only needed, because DatatypeConverter requires a java.util.Calendar, rather than a date (because a Date alone holds no TimeZone information). It only puts the date into a Calendar and sets the TimeZone to UTC.

XMPPDateTimeFormat is in this case even less flexible because its format() method always formats as UTC.

@XEP-0090: I only know of XEP-0013 which refers to it. I asked the XSF about it and Peter Saint-Andre told me XEP-0013 will either be deprecated or updated to use XEP-0082.

Florian Schmaus
February 11, 2014, 9:24 PM

I doubt that we need the flexibility to specify different timezones, as this data is likely only parsed by machines and not by humans.

February 14, 2014, 6:27 PM

If anybody's interested, I did a little test (DatatypeConvert vs XMPPDateTimeFormat), with the result, that DatatypeConverter is about 25% faster than XMPPDateTimeFormat, even if the Calandar object is newly created every time.

If you reuse the Calendar, its around double as fast.


Guus der Kinderen


Florian Schmaus



Expected Effort


Ignite Forum URL


Fix versions

Affects versions