Page MenuHomePhabricator

Expose wgLocaltimezone through mw.config
Closed, DeclinedPublicFeature

Description

Feature summary (what you would like to be able to do and where):
Get the timezone for the wiki (e.g. UTC for enwiki, Europe/Berlin for dewiki, Asia/Bangkok for thwikibooks, etc) using mw.config.get('wgLocaltimezone'). The value can be found in https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
This would be beneficial to Bawl to work on wikis with various timezones. Bawl reads the comment IDs (like c-Nardog-2022-01-09T21:23:00.000Z-Alexis_Jazz-2022-01-09T15:51:00.000Z) but they are always UTC so a conversion is needed. Currently the value is hardcoded per-wiki within Bawl with a dumb fallback to just assuming UTC, which is wrong whenever a wiki has a timezone that isn't UTC.

There are likely other gadgets that could use it.

Benefits (why should this be implemented?):
Currently this requires a query like https://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=general. This is more complicated, more error-prone and can result in reduced responsiveness.

If there is some concern with clutter or something, it wouldn't bother me if the value would only be exposed when it's not UTC, that's still easy enough to work with.

Event Timeline

(This doesn't look like something frontend, or to standardize across several codebases.)

Not really sure what the use case is. Do you want to show relative timestamps or something?

(This doesn't look like something frontend, or to standardize across several codebases.)

I had found T178487 which felt vaguely similar and was tagged with Front-end-Standards-Group, as far as I can tell by @TheDJ. But I probably misunderstood as, reading more closely, https://phabricator.wikimedia.org/project/profile/1616/ says "A project to track work for standardizing many of the interfaces, libraries and tools that our front-end engineers use." (bold mine) So script/gadget authors who aren't on Wikimedia's payroll are of no interest to the group.

Not really sure what the use case is. Do you want to show relative timestamps or something?

Bawl takes the timestamp from the comment ID like c-Nardog-2022-01-09T21:23:00.000Z-Alexis_Jazz-2022-01-09T15:51:00.000Z, this is AFAIK generated by DiscussionTools but the ID is always available whether you have DT enabled or not. Using this timestamp which is UTC regardless of wgLocaltimezone, Bawl tries to locate the comment in the wikitext. But the wikitext may or may not feature timestamps in UTC as that depends on wgLocaltimezone. So on thwikibooks it could never find anything, or if it does, it would be wrong.

@AlexisJazz: Maybe I misunderstood - are there different gadgets currently using *different* (emphasis mine) approaches to get that same wgLocaltimezone data (so their approaches should be standardized)?

@AlexisJazz: Maybe I misunderstood - are there different gadgets currently using *different* (emphasis mine) approaches to get that same wgLocaltimezone data (so their approaches should be standardized)?

https://en.wikipedia.org/wiki/User:TheDJ/signaturedetector.js and https://commons.wikimedia.org/wiki/User:Jack_who_built_the_house/Convenient_Discussions by @Jack_who_built_the_house get it from the API. If this feature request is declined, I think Bawl will make that API request exactly once, to store it in a cookie. More efficient than continuously wasting requests on what is effectively a constant, if a wiki changes its timezone, well, that'll a problem for later. (maybe I'll give the cookie a one-month expiration date)

On thwikibooks, you'll have worse problems, as the Thai projects also use a different calendar – note how all the dates are in 2562 or so.

On thwikibooks, you'll have worse problems, as the Thai projects also use a different calendar – note how all the dates are in 2562 or so.

You have a valid point: I should add support for various calendars. I hadn't actually tested it yet so I added the timezone for thwikibooks to Bawl to see. It actually does work even without that, but this relies on a less accurate fallback method. Still won't be as annoying as having to make an API call to get the timezone.

Edit: it would appear that their months and days are the same, only the year is different. That means the solution is is actually extremely simple. I'll just skip it. 🤣

Still won't be as annoying as having to make an API call to get the timezone.

i don't think its likely it will get added as a variable though. We are trying to do a lot to REMOVE variables from mw.config if they are not used by every single person visiting the page. So a dedicated/simpler api call mw.util.timeZone or something would be the most likely outcome.

(maybe I'll give the cookie a one-month expiration date)

Just use local/sessionStorage ? Cookies shouldn't be used for variable storage on sessions unless absolutely required.

I'll look into that. Since this won't happen and a simpler API call would require another task (which I probably won't file as I already added the action=query&meta=siteinfo&siprop=general thing to my script) I'm closing this one.