Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should server-time represent initial sent time of a message? #392

Open
linuxdaemon opened this issue Jun 25, 2019 · 2 comments
Open

Should server-time represent initial sent time of a message? #392

linuxdaemon opened this issue Jun 25, 2019 · 2 comments

Comments

@linuxdaemon
Copy link

The server-time specification is unclear with regards to something like PRIVMSG as to whether the time should represent the time the local server sent the message to the receiving client or the time the initial user sent the message. The examples section seems to indicate the tag represents the time the user sent the message.

Angel messaged Wiz at Wed, 19 Oct 2011 16:40:51.620 UTC

Can this be clarified further?

@DanielOaks
Copy link
Member

For something like PRIVMSG, I've always taken it to mean the time the original message was received by the server – there's been a lot of discussion in the channel about where this clarification would be most useful, the one of consideration here is around s2s and whether messages should have a consistent timestamp across the whole network (receiving server attaches timestamp, all other servers on network use that when sending) or it's not that important (all servers attach their own timestamp when receiving it via s2s). Where possible I reckon the first one is best, but it probably wouldn't cause (m)any dramas to do the second. This may not be something to clarify in the spec, but if we do it should be in a non-normative implementation considerations section.

The channel discussion went further into how clients should be acting in terms of reordering incoming messages or not based on server-time, and the issues that could be caused by actively reordering based on it (assuming that clocks between servers could shift a bit). Perhaps some advice like clients should only reorder messages based on their @time tag if they're contained within a chathistory batch would make sense somewhere, but I'm not sure how necessary advice like that is.

@edk0
Copy link
Contributor

edk0 commented Jun 26, 2019

FWIW (since it was said enough times in the channel), reordering messages inside chathistory is just as broken as reordering them at any other time. It's not hard to sort the messages before returning them; if a server chooses not to do that, it's likely as not because doing so would be wrong.

As with the argument on IRC about non-chathistory messages: short of funneling everything through one place, you cannot send the same time to everyone and have the times reflect the order in which things really happened.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants