(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?

In T298884#7610735, @Aklapper wrote:

(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.

In T298884#7610782, @Nardog wrote:

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)?

In T298884#7610892, @Aklapper wrote:

@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.

Related: T21992: Support client-side date/time formatting for user's timezone, language, and preferred format (JavaScript)

In T298884#7611296, @matmarex wrote:

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.