Community Wishlist Survey 2023/Bots and gadgets/Allow client-side scripts to convert dates in the format used in MediaWiki interface

Add links
From Meta, a Wikimedia project coordination wiki

Allow client-side scripts to convert dates in the format used in MediaWiki interface

  • Problem: Software, including MediaWiki APIs, usually handles dates in Unix time (e.g. 1672543856) or ISO format (2023-01-01T12:30:56Z), but MediaWiki shows them in human-friendly formats such as "04:30, 1 January 2023" or "2023年1月1日 (日) 20:30". But script developers have no access to the logic according to which these formats are produced (or even the difference between the user/site's time and UTC, which can vary with DST) and can't show dates in a way that is consistent with how the user sees the rest of the MediaWiki interface.
  • Proposed solution: Expose the server-side logic for formatting dates for each language/format through an API and develop a JavaScript library, perhaps as an extension to mw.language, that can convert a date in the format set by the site or user (and preferably vice versa).
  • Who would benefit: Users and developers of MediaWiki and its extensions, gadgets and scripts
  • More comments: PageTriage even replaced JavaScript's native Date object, which obviously ran into problems, so now it uses the Moment library, which is also to be replaced. Even then you can't account for every one of the numerous ways users see the MediaWiki interface without an unreasonable amount of reinventing the wheel, because various users, sites and languages use not only different timezones but different numerals, eras and calendars.
  • Phabricator tickets: T21992
  • Proposer: Nardog (talk) 06:51, 6 February 2023 (UTC)[reply]

Discussion

  • @Nardog: To clarify, this proposal is about exposing an API function to convert date/times (such as the timestamp 1672543856, or the ISO 8601 2023-02-07T20:16:29+00:00) to "human-friendly" date/times, such as those specified in Special:Preferences? — TheresNoTime-WMF (talk • they/them) 20:19, 7 February 2023 (UTC)[reply]
    @TheresNoTime-WMF: As opposed to...? The answer is yes, of course, but I'm not sure what I'm supposed to clarify between. If it's between a synchronous function that can convert dates completely offline (once the module is downloaded) versus an asynchronous one where you have to send the dates to the server every time, the former is obviously preferable, but failing that, an option to receive dates in a specified (or user-preferred) format in conjunction with the Unix/ISO dates in the same API call (much like you receive canonical page names) would be very handy, as those would be the primary use cases (I ran into the present problem as I built CatChangesViewer and MoveHistory, where I'm begrudgingly showing dates in ISO/UTC).
    AFAICS, the pieces of information needed to show a date in the same format as the MW interface are: timezone, format, numerals, era, and calendar. And currently only numerals are fully avaialble (via mw.language.getDigitTransformTable()). mw.user.options.get('timecorrection') gives only one value for the UTC offset so it's of little use; you have to match the location with a timezone database (which Moment provides—perhaps the data should be its own RL module). The formats (like H:i, F j, Y) are in /languages/messages/. AFAIK they aren't available through the message or languageinfo API, and it'd be swell if they were. The logic for non-Common eras and non-Gregorian calendars (in use in Iran, Thailand, Japan, etc.) appears to be in Language.php. It doesn't look too complicated to port to JS but it'd be nicer if both server and client used the same codebase.
    (The opposite direction (from a formatted date to a computer-friendly one) is harder and probably in less demand, but come to think of it, it's exactly what DiscussionTools has figured out, isn't it? It's how it tells where each comment ends and the next begins after all. Exposing that function as an asynchronous API might prove useful.)
    Now I'm realizing none of these seem like "less than a year-long project", and I'm talking myself out of the original proposal! How about changing the solution to something like:
Proposed proposed solution

An option in Action API that, if the response contains any dates, appends versions of them in the language/format/timezone specified in the request (somewhat similar to the "normalized" object in action=query). It should accept values like "site" (the site's default format) and "user" (the logged-in user's preferences) in addition to specific languages/formats/timezones (like uselang). And a separate but similar API function that receives acceptable timestamps and returns them in the language/format/timezone specified in the request.

Nardog (talk) 00:31, 8 February 2023 (UTC)[reply]
Thank you, was just wanting to make sure I understood the scope correctly As an aside, this would be a really useful thing to have from my own volunteer dev experience wrestling datetime formats.... — TheresNoTime-WMF (talk • they/them) 10:16, 8 February 2023 (UTC)[reply]
Okay, then I guess the alternative above should be thought of as a starting point or an acceptable compromise. Nardog (talk) 18:36, 8 February 2023 (UTC)[reply]
  • Modern Javascript has Intl.DateTimeFormat which is very capable (arguably more capable than MediaWiki's server-side logic). Unless your goal is to very specifically match the server-side date format, or to parse human-readable date strings back into numbers, you are probably best off doing that. --Tgr (talk) 03:12, 11 February 2023 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Bots_and_gadgets/Allow_client-side_scripts_to_convert_dates_in_the_format_used_in_MediaWiki_interface&oldid=24591930"