I am not talking about delayed message. Delayed message can be got from stamp
But how about a live message ? Does Openfire support that ?
The only information I see on the Internet is XEP-0131: Stanza Headers and Internet Metadata However, Openfire does not support this XEP.
Please tell me how to resolve this. And I need server time because client time can be wrong. Thank you. Why such an obvious thing like this is not included in the message …
Anyone knows how to resolve this?
Live messages are just the current time when they are received on the client ± a few milliseconds for TCP transmission.
If you want to attach an extension in Openfire and add the server time to each message, you need to write a plugin and intercept each message (see InterceptorManager).
I told you that using the client time can be incorrect because client time can be wrong.
actually get the client time is a bit okay, it will show the time according to the client time . However, the stamp time I get from delay messages still use the server time. This leads to conflict if client time is different from server time. Anyway, it looks like there is no other way at this moment.
It’s probably the best to fix the client clock. Let’s say it goes 17 minutes wrong, the “live” messages are of course displayed 17 minutes wrong, too, but still correct relative to the client clock.
CSH, are you saying that live messages don’t have any server’s time stamp on them? I thought they still have them, but a client decides whether to use them or attach its own stamp instead. But if only offline messages have them, that explains why Spark is showing server’s time while receiving offline messages and not for live ones. Then my ticket is wrong (unless attaching additional extension to the server): https://igniterealtime.org/issues/browse/SPARK-1586
Yes, live messages don’t have any timestamp. They are real-time, so a timestamp wouldn’t add much value, except maybe a few milliseconds.
The timestamp which is attached by the server, is the time when the server received a message and couldn’t deliver it. So in other words it’s the send time. If the timestamp is absent, the send time is “now”.
Thanks for the clarification. Though, there might be some minor use case for using server’s time stamps (when clients are scattered around the world and a user would want to see when the messages was received by the server), but the more i think, the more useless i find this case.
todaf is explaining this requirement that a client time can be wrong. But what does showing a server’s time solve in this case? Say user’s clock is +15 mins than it should be. Server receives a message at 14:30 and sends it right away to the client and attaches 14:30 to it. The user was away for a minute from his machine, he looks at the message at 14:46 by his clock and sees that he missed the message by 16 minutes, then in the reality it came just a minute before. This just creates more confusion than solving anything. Unless it is used in some automated system which uses xmpp for functioning and not for human conversation usage. I’m closing my ticket with “Won’t fix”.
Yes, right, wroot. If the client time is wrong, a (correct) server time stamp wouldn’t help much here as it probably leads to more confusion as your described. If the client’s clock is behind, a user will even see times which are in the future and get confused, too.
This can happen with offline messages as well, if the client uses the delayed delivery extension to display the send date (this is what I prefer).
So the real problem is the client clock, which should get fixed. Aren’t modern clocks synchronizing with the internet anyway?
I do not think using server time will create any confusion. If there is, it should be very little. Using server time will make all users use the same clock time. If using client time, in case of wrong client time, Other users will not understand it when they receive the message of an user with a wrong client time. For the user has the wrong time himself, it may create a little confusion but he then should notice that he has a wrong clock time right away. It create a huge confusion for all other users when they receive the message from that client with a wrong time.
Using client time, it is only a little okay because there is currently no other way to do it at the moment.
There is another way to counter this is to compare the client time with the server time at the beginning, get the difference between them and adjust it correctly when displaying to all users.
Other users will not understand it when they receive the message of an user with a wrong client time. For the user has the wrong time himself, it may create a little confusion but he then should notice that he has a wrong clock time right away. It create a huge confusion for all other users when they receive the message from that client with a wrong time.
I think you misunderstand that. Users won’t see another user’s client time, when they receive their messages, because client time is not attached either.
They just receive a message, usually in real-time, and display it with what is “now” in their clock. But it’s totally independant from any other wrong clocks in the system.
So, when they receive a message at 11:37 to their clock, but the real (internet) clock, is 11:35, it should be displayed as “11:37”. If the sender’s clock is 11:40 already, you won’t know that.
Yes, you can probably synchronize a client’s clock with the server using XEP-0202, and add the difference to your client clock to each message, but this is unnecessary complexity imo.
CSH already explained this (local time of a sender is not sent anywhere).
but he then should notice that he has a wrong clock time right away
A bit of offtopic here. I’m a bit of pedantic person myself, but a rarely look at time stamps when chatting with colleagues. So unless you work with some maniacs or have a very strict rules to check time stamp of every message i don’t think someone will notice such thing right away At work i sometimes find users with wrong time and date (antivirus program complaining about wrong clocks) and often they are working like that for a week or so and don’t notice this.
Yeah, I misunderstood it here. The client time is Now in their clock when they receive the message. That is better and okay. However, still the problem is that the delayed message stamp using server time are not matched with the client clock. I still feel there should be an easy way , as easy as getting the stamp from delayed messages.
wroot: Yeah I wrote in the earlier post that I misunderstood. At this moment, I will accept that error when stamp of delayed messages are different from the client time. It is awkward and not good to adjust stamp of delayed messages to the client time especially when it is a wrong time. Just leave it there is good. I think that is okay.
However, still the problem is that the delayed message stamp using server time are not matched with the client clock.
That’s right. E.g. server receives a message at UTC 00:00 but can’t deliver it. Receiver comes online at UTC 00:30, but his client clock is +2 minutes wrong. In this case the client thinks the message was sent 32 minutes ago, although in reality it was sent only 30 minutes ago.
There’s not much you can do about it.
You could write an Openfire plugin which attaches the delayed delivery extension to every message, so that all messages have a (server) time stamp attached. But it’s still an unusual case. Seems like in 15+ years of XMPP nobody ever asked to solve this.
Are you talking about Spark or any other client? Because i think this is a client issue and not the server’s. Server is sending a delayed delivery time stamp with a delayed message to the client, and then it is up to the client to decide what to show and how. XEP-0203: Delayed Delivery defines that i think.
I have filed a ticket a while ago for Spark. Though i have changed it recently. I thought Spark should always show only the local time when receiving any message. But then i decided, that having a delayed time stamp could be useful in some cases. Currently Spark only shows a delayed time stamp when receiving an offline message, but if you close and reopen the chat window it will replace it with a local time. In first comment i propose to save and show a delayed time and date stamp before the local time stamp. Not sure how hard it is to implement and currently Spark doesn’t have active experienced developers.
If you are using some other client, when maybe you can contact its developers to try and handle such cases.
Hello my friend.
Did you solve your problem?
I´m having the same problem, i need to know if is there some way to server send the timestamp for all messages or, to syncronize my app with the server time.
Write simple packet interceptor that will append timestamp to every outgoing (or incoming message) message as an extension. Extensions can be easily read back on client side (I am using Smack)