Bartosz Małkowski opened 6 years ago
|
|
‚TimestampHelper’ class was created while I was working on MessageArchiving support and was part of MA jar. Later on, as I was working on better support for time zone handling I’ve discovered that ‘DateTimeFormatter’ was not properly handling this information, so I’ve decided to replace it with ‘TimestampHelper’ which was handling different time zone correctly. To be hosnest usage of so long milliseconds part is weird for me and I’ve never tested support for that. Even databases on our schemes are keeping only milliseconds precision (3 positions after the seconds part). Best it would be to modify ‘TimestampHelper’ to correctly handle that. However, code in ‘DateTimeHelper’ was not very readable and not handling time zones correctly, so we should add it as a special case to what ‘TimezoneHelper’ does right now. I can handle it next week if it can wait. If so, then please reassign this issue back to me. |
|
If you don't like I have no idea why they use so big precision. But I think we should be able to parse it. Of course we still can create three digits ms part in our code. |
|
I reimplemented Helper, added tests. Old |
|
I've reviewed changes and they look ok, however now TTS-NG returns a lot of errors. I've created task #8103 to review results and fix those issues so that I could confirm that this change has no negative impact on the rest the server. |
|
Now it looks that TTS-NG is not returning any errors after applying a fix in Jaxmpp2 timestamp parsing. Closing issue. |
Type |
Task
|
Priority |
Major
|
Assignee | |
RedmineID |
8092
|
Why you created class
tigase.util.datetime.TimestampHelper
instead of use (and extend?)tigase.util.datetime.DateTimeFormatter
?Because of this, I cannot join to MUC room from Swift because it uses more detailed timestamps:
2018-08-21T08:48:22.792921Z
and this format is not supported by helper.Here is test for that.