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

server-time: mention echo-message & NTP #199

Closed
wants to merge 1 commit into from
Closed

server-time: mention echo-message & NTP #199

wants to merge 1 commit into from

Conversation

Mikaela
Copy link
Contributor

@Mikaela Mikaela commented Dec 29, 2015

2015-12-29 20:43:24+0200 < AttilaM> Mikaela: go ahead, write it
2015-12-29 20:43:28+0200 < AttilaM> then we can decide where it fits
2015-12-29 20:47:07+0200 < Mikaela> sure, I know that it won't be accepted at first and requires heavy fixixng, but at least then you must give constructive comments

@Mikaela Mikaela changed the title echo-message: mention echo-message & NTP server-time: mention echo-message & NTP Dec 29, 2015
@SadieCat
Copy link
Contributor

I don't see the point of this. If your clock is wrong then you should expect invalid timestamps.

👎

@dequis
Copy link
Contributor

dequis commented Dec 29, 2015

I think these issues should be documented somewhere, and maybe the server-time spec is not the right place for it, but we can't ignore the issue completely and keep it as something that only those involved in the discussions / bug reports are aware of.

@progval
Copy link
Contributor

progval commented Dec 29, 2015

What if the client could ask the server to give timestamps relative to when messages are sent?

@grawity
Copy link
Contributor

grawity commented Dec 29, 2015

Would be simplest to make the server advertise its current time, as a general feature similar to what many s2s protocols have.

This would also be useful for adjusting timestamps in MODE replies, in WHOIS, in ban lists, and so on...Optionally claim that this may also be useful for STS etc.

Clients concerned about incompetent server admins can then determine the offset between server time and local time.

Either redefine the TIME numeric reply to include a machine-readable timestamp parameter which it unfortunately lacks, or define an ISUPPORT token TIME= with the server's current timestamp, or define an (advertise-only) cap time= with the same.

Anything else is useless. Reminds me of "Caution: Hot coffee may be hot" kind of warnings.

@DanielOaks
Copy link
Member

CAP dan- LS :server-time=2011-10-19T16:40:51.620Z ?

@grawity
Copy link
Contributor

grawity commented Dec 30, 2015

@DanielOaks: That was also a version I considered (as well as requiring 001 to be time-tagged), but again this might be useful even if the server doesn't support @time tagging, so...

@DanielOaks
Copy link
Member

Hmm, well in that case it will still present the current time to the user on connection, even if they don't explicitly enable it. Interested clients should be able to work it out based on when the CAP LS comes from the server anyways, so shouldn't be any need to explicitly time-tag 001?

We already time-tag 001 in mammon, but I'm not sure how requiring something like that would break other bits of software. If we really need to put this as another numeric or something (like RPL_TIME but with a standard, parsable format like above), I think that may work best as another spec or as a 3.3 thing.

@grawity
Copy link
Contributor

grawity commented Dec 30, 2015

Hmm, well in that case it will still present the current time to the user on connection, even if they don't explicitly enable it.

Still implicitly requires tag support on the server though, while a dedicated time= cap would be usable even by older ircds.

@Mikaela
Copy link
Contributor Author

Mikaela commented Dec 30, 2015

The reason I am opening this PR reads in the original comment and in case someone missed it at IRC, I want it to be documented somewhere, so client authors/developers don't go following issues like znc/znc#1144 and remove server-time (even if this only wanted to reduce server-time).

I am open for other ideas too, but I am afraid my skills are limited to this PR unless I get a lot of help.

I think the spec is the best place (when language is fixed), because all developers are going to read it and it's not so big part of the spec.

@jwheare
Copy link
Member

jwheare commented Dec 30, 2015

For reference, here's how we manage clock offsets in IRCCloud's JSON stream api.

On connect to the API stream, a header message is sent which includes the server's current time as seconds since the epoch. We use this to calculate the offset between server (bouncer) and client (browser)

TimeOffset = new Date().getTime() - (header_time*1000)

Then when it comes to displaying a message to the user (also timestamped by the server) we apply the offset like so:

timestamp + TimeOffset

This stops users from complaining that their message times don't match their clock.

One side effect to note is that message timestamps can vary between web client sessions, but only one particularly vocal user has complained about this ever.

I'd be in favour of a note saying client authors MAY implement timestamp offsetting to match the user clock.

@jwheare
Copy link
Member

jwheare commented Dec 21, 2016

Closed in favour of #290

@jwheare jwheare closed this Dec 21, 2016
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

Successfully merging this pull request may close these issues.

7 participants