Request time null formatting

Doing some testing, I found that #time will return the formatting string unmodified if the string has no recognized code (or throw an error if the date object is bad). However, it does not appear that #time has a null code to return the date/time object unmodified (or throw an error if the date object is bad). This behavior would be useful for several templates using #time for data validation that would otherwise want to defer to the user (or source) for date formatting. It also seems to me like it would be an expected feature for any parser function, unless I'm missing something. SamuelRiv (talk) 22:26, 5 April 2024 (UTC)

Could you please demonstrate the current and desired behavior using an example? Matěj Suchánek (talk) 08:47, 6 April 2024 (UTC)

Unrecognized or blank formatting string: {{#time:q|1999-01-01}} ; {{#time:|1999-01-01}} ;

q ;  ;

What I request is a formatting string code that validates the date/time object and returns the date/time object string unmodified if valid. Something like {{#time:NULL|1999-01-01}} ; {{#time:NULL|1999-99-99}} would return output 1999-01-01 ; ERROR_CODE.

The reason for requesting this is it seems like null behavior is missing in either case -- the current behavior seems to indicate that some null date would output the formatting string unmodified, but that function is not present either (I don't know what the use case is for outputting unrecognized characters in lieu of an error code). Either way, some kind of null function behavior should be expected unless there's a good reason. (Alternatively, validation should be separable from reformatting.) SamuelRiv (talk) 03:30, 10 April 2024 (UTC)

Can’t you use #iferror?

{{#iferror:{{#time:|{{{1}}} }}|Error|{{{1}}} }}

Tacsipacsi (talk) 15:50, 6 April 2024 (UTC)

Tracking pages with expr errors

If a page is published with the code {{#expr: 1+ }}, it will show a localizable error message in the page body. Here's an example: User:Amire80/oneplus.

Is there a way to find a list of pages that have such errors, e.g. a tracking category or a special page?

As far as I know, there is no such page at the moment.

In the Hebrew Wikipedia, the administrators changed the messages that show these errors so that they display the message and add a page to a category. It works, but it's hacky. Is there currently no other way to do it? (That is, other than modifying the code that implements {{#expr.) Amir E. Aharoni {{🌎🌍🌏}} 18:58, 9 April 2024 (UTC)

Amire, you are clearly abusing your admin privilege, by administratively deleting an answer (and hiding its content in the history) that was on completely topic, and no so long as you state. It also explained what could be done for now and what may eventually be done in MediaWiki to solve such problem.

You say it was not replying the question. But what was really the question? The current lack of support in Mediawiki and the way it works and how error trackings in categories may (or may not) be done in the result of a parser function that is not supposed to return such thnig in the plain-text format (excluding MediaWiki and HTML tags) expected in return by this function.

As your question has no definitive answer for now, I explained a workaround, currently used in many templates (and their possible caveat, minor in most existing usage cases, using "#iferror"). And it was properly formatted. It's not my answer that is too long, but your question which is badly formulated, and is in fact exposing a problem, seeking for solutions or workarounds (what I did). If you don't want any opinions exposed to this case, why posting here to the public? I did not violate any rule here, but you just did it with your privileges. Verdy p (talk) 16:24, 10 April 2024 (UTC)

I stand by what I've written in the deletion comment: Your response was very long, and it didn't answer the question. I asked a simple yes-no question that can be answered clearly and briefly, as was done in another response. If you don't understand what the question or don't have the knowledge to answer it, you don't have to write anything. I deleted your response because it could make people think that the question was answered, even though it was not.

In fact, a very large number of the responses you write on Phabricator and on discussion pages in all the wikis in which I saw you writing are too long and off-topic, and I'm really not the only person who openly complains about that. Amir E. Aharoni {{🌎🌍🌏}} 16:42, 10 April 2024 (UTC)

Seeking for solutions (this was clearly not "a yes-no question") and discussing them (because you instantly replied "no" to your question, without discussing possible solutions) appropriately is on topic, and does not justify at all your administrative deletion. You've abused your rights. Verdy p (talk) 16:45, 10 April 2024 (UTC)

I keep track of these errors using simple search: .

And yes, we have Manual:Tracking categories, but we definitely don't track all errors. Something needs to be changed in the code. Matěj Suchánek (talk) 16:14, 10 April 2024 (UTC)

I suggested (in the message abusively deleted by Amire80) to implement some code in MediaWiki to allow a parser function to post error tracking messages in an alternate "stream", not returned in the single string by the function call, but that would be generated after the main content. For now there's no easy way to correctly implement error tracking in parser functions like "#expr:", and that would not cause further problems to the parsing (it can potentially break the page layout or HTML syntax). Amire80 thinks it is "out of topic", but this is not. The pseudo solution he gave above is not one (described by himself as "hacky", so it was explicitly seeking for better solutions), so for now we use workarounds (like "#iferror:" in templates, to detect errors in expressions, because there's still no other way to do that without modifying the wikicode of pages using "#expr:"). Verdy p (talk) 16:54, 10 April 2024 (UTC)

Time issue

Does anyone know what's happening when I run {{#time:d M Y|2017 + 13 months}} and get 15 Jun 2026? It doesn't read 2017 as a year and adds 13 months to the current date. Sdkb ^talk 22:51, 9 April 2024 (UTC)

Months are 30.436875 days on average (in the Gregorian calendar, whose years are 365.2425 days on average), but their actual length on calendars is variable and adding months would depend on the starting month and possibly the day, and sometimes on the year if it's in February on leap years (notably when starting on the last few days of months). But calendar months within a year (counted from 1 March to the next year) are aligned as if their length was 30.6 days on average, before rounding the number of days, so distinct calendar months are variable in duration.

When you specify 2017 alone, there's no way to add an exact number of months and get a date with a precision to the day. The function takes the missing month and day from the current date (9 April 2024), and then adds the relevant number of months. The specification "2017" is ignored.

That function could use 1 January of 2017 at 00:00:00) as the base (independantly of the current year) and then add 13 months: 12 months to increase the year from 2017 to 2018, then 1 month to shift from 1 January to 1 February, resulting in 1 February 2018 (at 00:00:00, but you did not tell the function to show the exact time).

When you add a number months it is more simply converted to a number of years, by just dividing this number by 12. The function would then add 1 year and 1 month, but at which day of the month? Some rounding must occur. Other interpretations are possible.

But generally it's not a good idea to add months to any date without specifying an exact date with a precision at least to the day (independantly of the display format "d M Y", which plays no role here).

In NO case you can expect a resulting date in 2017. Verdy p (talk) 07:13, 10 April 2024 (UTC)

Thanks for the reply! I'm working on a template where neither the precision of the date nor the units of time in the addition are known in advance. To get around this issue, I had to implement a workaround converting the date to the more precise DMY format (which borrows the current day/month when not specified) before putting it through w:Template:After, which uses unix time. If you know of a better solution, feel free to lmk or tweak the template yourself! Sdkb ^talk 15:17, 10 April 2024 (UTC)

Add functionality to the letters “S” and “E” (and replace functionality of letter “I” if possible)

As you know, the lowercase letters s and i correspond to the second and the minute respectively, both zero-padded, however, unlike hour, these do not have not zero-padding number equivalents, I suggest assigning to the S the not zero-padded second, and, if it's not too much trouble, replace the functionality of the I with the not zero-padded minute, and assign that other functionality to the letter E, if not possible, then assign to E the minute with not zero-padding, although it would not be so coherent. 95.143.193.15 (talk) 04:11, 30 September 2024 (UTC)