So we have a glitch/bug that SQL triggered (inadvertantly) when he jokingly went to proceed to block the user Oshwah on enwiki. SQL set the block to expire in 3.14159265359 seconds and it ended up generating a block log entry "SQL (talk | contribs) blocked Oshwah (talk | contribs) with an expiration time of 06:36, 18 January 1975 (autoblock disabled) (I'm sure I'll have to apologize for this later. WHEEEEEE)". Noticing this SQL promptly unblocked and apologized. But it gets wierder as the block message to Oshwah appeared to claim that the block was set to expire on 11:36, 10 May 2021.
The block time is parsed using PHP's strtotime() function (see SpecialBlock::parseExpiryInput()). strtotime() is known to be extremely lenient and prone to interpreting very stupid inputs as valid values. Other fun block durations to try include "100000 years" and "a potato" (see T51580).
In this case: strtotime( '3.14159265359 seconds' ); → 1620646599. This happens to be the Unix timestamp for Monday, May 10, 2021, 11:36:39 UTC. I'm not going to even attempt to figure out where this output comes from, but it sure does.
I think this is the expected behavior.
Oops, sorry Cyberpower for removing you as a subscriber ... I was trying
to figure out how to subscribe *myself* and was having great difficulty
due to my screen reader. I finally managed it with Firefox ...
Now that I think about it, further examples might help. Both of these displayed correctly when I did them (2008/2009), but no longer do so.
Firstly, I blocked myself as a test for 2.71828 seconds, which now displays as 02:37 (UTC), 1 January 1970:
Then I blocked Giano for what was supposed to be 3.14159 seconds, but apparently appeared as 3 hours, here:
That block now displays as 03:16, 1 January 1970 (UTC).
The function is supposed to check for strange values itself. It does reject some inputs, at least. Trying to second-guess it and writing our own parser doesn't seem very worthwhile to me. It seems that the only situation where this causes problems is joke blocks. ;)