Seems expected, when a information in the input (like day or year here) is missing, the current day or year is used (or in other words: The input is relative to the current time). Making this bug appear "fixed" tomorrow, because the missing information "day" is using "1" tomorrow, which is not an overflow in "february". The 30 or 31 is an overflow and march is the result.

Be more precision on the input
https://www.php.net/manual/en/function.strtotime.php#refsect1-function.strtotime-notes

Note:

"Relative" date in this case also means that if a particular component of the date/time stamp is not provided, it will be taken verbatim from the baseTimestamp. That is, strtotime('February'), if run on the 31st of May 2022, will be interpreted as 31 February 2022, which will overflow into a timestamp on 3 March. (In a leap year, it would be 2 March.) Using strtotime('1 February') or strtotime('first day of February') would avoid that problem.

It seems impossible to fix this without breaking the wiki pages, so I support WONTFIX here.

Previously: T52477

It might be a good idea to document this better at https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions##time. The documentation kind of explains this:

the function will "fill in" parts of the date that are not specified using the current values

{{#time: Y m d H:i:s | June }} → 2022 07 01 00:00:00 Gives the start of the day, but the current day of the month and the current year.

The function performs a certain amount of date mathematics:

{{#time: d F | February 29 2007 }} → 01 March

…but it doesn't really help you connect these two facts to realize that if you just write "February", you might get March.

i used

{{#time:F|February|{{int:lang}}}}

basically to translate it into different languages.

no one would expect that if asking the software "what's the french word for 'February' in your system?", the software would stupidly fill in a date based on the current date and then answer "the french word for 'February 30' in my system is 'mars'!"

and the problem is not limited to February. on the 31st day of any month, for all the months without the 31st day, this error will occur.

why would it fill in a date? and why filling in based on the current date and not the 1st or 14th/15th day? if on 31 dec i say "in april i bought a house", by any logic i mean i could have bought a house on any date in april, but never is it possible that i meant 31 april = 1 may.

php being stupid is not a reason mediawiki should be as stupid as them.

no one would expect that if asking the software "what's the french word for 'February' in your system?", the software would stupidly fill in a date based on the current date and then answer "the french word for 'February 30' in my system is 'mars'!"

That's one point of view. The other is: if you want to have something translated (what's the french word for ...), then maybe doing such a roundtrip and involving calendar stuff is... somewhat complicated. Just use existing internationalization means, such as {{MediaWiki:February/fr}}.

thx for the tip. that enabled better codes for https://commons.wikimedia.org/w/index.php?oldid=702252233 .
but in order to do that, one has to know such things exist first. how on earth would i know which things have i18n like this?
even with your tip, i went to translatewiki to try finding the version for abbreviated months. i found it only when i attempt to translate MediaWiki:February, a table of three forms of month names (short, long, genitive) popped up on the side, and i found the code for the short form in the links in that table.
rather extreme manoeuvres to find a mediawiki message.

In T321989#8365615, @RoyZuo wrote:

…
and the problem is not limited to February. on the 31st day of any month, for all the months without the 31st day, this error will occur.
…

Exactly.
All month 31 where month has max 30 days in incremented and day(s) wrapped, e.g.:

• {{#time:Y-m-d|2000-02-31}} ⇒ 2000-03-02
• {{#time:Y-m-d|2001-02-31}} ⇒ 2001-03-03
• {{#time:Y-m-d|2000-04-31}} ⇒ 2000-05-01
• {{#time:Y-m-d|2000-11-31}} ⇒ 2000-12-01

Not sure if separate phab issue should or does exist for that.
UPDATE: does exist now: T411471: #time parser function silently "mitigates" incorrect dates with month days overflow instead of producing error
(note: issued/updated unfortunately without being aware of quick following post, which explains much)

( … or maybe rather not so exactly. Whatever month 32 and more causes real red error.

• {{#time:Y-m-d|2000-01-32}} ⇒ Error: Invalid time.

)

https://www.php.net/manual/en/function.strtotime.php is mostly to blame. T178175 more or less covers this.