Hey, everyone! It's possible you've noticed on some articles and templates that a date in the editing field doesn't match the formatting of the date displayed on the article. This is because I've been implementing a small magic word function, called formatdate, into some templates. What this does is it'll allow us to be a little more consistent in displaying our default date formatting of choice (ISO 8601) to logged-out users without having to worry about what formatting editors used when inputting the information.
Specifically, this function reads whatever date formatting is inserted into the relevant template field and then spit it back out into a chosen date format. For logged-out users, that date will always be the default ISO 8601, i.e. YYYY-MM-DD. Logged-out users will always see that formatting. It doesn't matter if one editor puts in a date format of "July 19, 2021" and another puts in a format of "19 July 2021". All logged-out users will see "2021-07-19" every single time, no matter what.
Now, what about logged-in users? This function will display the date in a formatting set inside the logged-in user's preferences. (You can check your own preferences underneath the "Appearance" tab in your preferences.) For me, my preferences are set to "Month Day, Year" so all dates inside templates using this function display that way for me. If the logged-in user has chosen "No preference", then the date will display for them as the default ISO 8601 as well.
To picture this in action, you can visit the article for "By the Road", as Infobox Episode is one of the templates that now includes this feature. At the time of writing, the date in the Infobox under Airdate displays to me as "July 15, 2021", but it may appear different to you. If you cycle through your date preferences and refresh the article each time, the format of the airdate in the Infobox changes to reflect that new formatting, but if you open the article up in the editing form, you'll see that it's entered in as "2021-07-15". As a second example, if you check out the references in the Behind the scenes section of Opal's article, you'll notice the same thing happening. This is also a good example to illustrate what our logged-out users will see: open Opal's article while logged out (a private browsing tab will do), and you'll see the dates default to ISO 8601, even though the dates are entered into that template in "Month Day, Year" format.
"But," you might be remembering, "a lot of episode Infoboxes input MORE than a date in the Airdate field? I noticed you separated out the airtime into its own field to get this to work," you may have noticed, "How are those currently displaying?" Currently, those articles are displaying exactly the text the editors input into that field, i.e. they look exactly the same as they always have. The formatdate function looks at the bit of text, and if that text doesn't exactly match a date formatting, it simply displays the input text in an unaltered form. So, the Infobox Episode template sees something like "2019-08-22 19:00 PDT" in the airdate field, and it just doesn't mess with that at all and displays that text exactly as is. You can observe this behavior on the current (as of writing) revision of the article for "Refjorged".
In summary, the function allows dates across the wiki to appear more consistently and better ensure that ISO 8601 is displaying as the wiki's default date formatting. At the same time, it allows us to respect the date formatting preferences of our logged-in userbase in a similarly consistent manner—and thus likely preserving their reading comfort.
Currently, the templates using this function are:
I'm intending to embark on a slow project to separate out the airtimes the episode articles into their own fields to properly enable this function across those articles. It is not of a high priority because of the mentioned behavior where the function displays unrecognized text as is, but if you wish to make the change yourself while you have an episode article open, feel free.
If you have any other templates you think this magic word (yes, it's really called a magic word) would be useful in, let me know! Again, there's a low risk to implementing the template because that unrecognized text behavior means it won't break any existing formatting, but the reward of more consistency and comfort is great.