search

ergochat / ergo

A modern IRC server (daemon/ircd) written in Go.
https://ergo.chat/
MIT License
2.27k stars 180 forks source link

user preference for timezone #712

Open slingamn opened 4 years ago

slingamn commented 4 years ago

See #710, for example: if set, all user-visible timestamps will display in the user's timezone.

slingamn commented 4 years ago

Increasingly relevant now with HISTSERV PLAY.

slingamn commented 4 years ago

We might also want to have a default timezone for the server in the config.

slingamn commented 4 years ago

I implemented this but the results were pretty unpleasant. In particular, it's very challenging to provide a sane interface for picking a timezone.

I'm probably going to bury this in the stack for a while.

ell1e commented 4 years ago

Wouldn't it make more sense to ask for some sort of IRCv3 extension to always send all times given as UTC, and then get clients to adopt that extension to recognize this and do the translation locally? Trying to track user timezone reliably server-side doesn't seem like worth the effort, and all users who care will make sure it's correct on their local devices they use

slingamn commented 4 years ago

I think most of the cases you're describing are covered by the server-time extension, which is always UTC.

This issue is about responses that can't really be standardized, either because:

  1. They're for idiosyncratic vendor stuff that we do, for example, /nickserv sessions, which is specific to our multiclient feature
  2. They're part of workarounds for clients that lack support for the relevant IRCv3 feature, for example, /histserv play, which is a workaround for clients not supporting draft/chathistory. draft/chathistory uses the server-time tag to carry time information, but /histserv play needs to work with clients that don't support tags at all, so we're stuffing the time into the text of a fake PRIVMSG from HistServ!HistServ@localhost.
DanielOaks commented 4 years ago

Yeah we already send all machine timestamps (the ones where the timezone is a separate param) as UTC, this seems more for when we turn those times into text, and that's done mostly by services afaik.

  1. we could advertise an informational cap like oragono.io/tz=utc to indicate that all times are sent in UTC (the old ones that don't have any TZ info anyway, all the ones introduced by v3 have the TZ at the end of the timestamp) -- is anything like this desirable or is it widespread enough that clients can just assume all timestamps they receive are UTC already?
  2. is it worth having a way for clients to automagically tell the server what timezone to use when the time is in text? I dooon't really think so, probably not? I can't see much of that being used outside services. given the hacky nature of services the real solution there might just be to present that functionality more natively, so we can send clients proper timestamps in the way the new v3 stuff does.

^, maybe some interesting context in this comment too though

ell1e commented 4 years ago

Isn't the CTCP the protocol for inline markings for special client processing? (The one that also does the special /me stuff) Maybe some extension to that could be proposed to mark UTC times inside text so clients can replace it with local time? That is the only other idea I can think of