Page MenuHomePhabricator

High-precision block times are misinterpreted as time of day and duration
Open, LowPublic

Description

Author: ais523

Description:
See the URL above (permlink given in case the report is archived). It seems that a user
was blocked for "2.37685 weeks", and MediaWiki interpreted that as "02:37 after 685
weeks". This behaviour is certainly unintuitive, and should either be an error or act as
expected (i.e. block for a bit over 2 and a third weeks). Version is current Wikipedia
(Special:Version says 1.10alpha, but that's not in the list, so I've left it as
unspecified and commented here instead).


Version: unspecified
Severity: normal
URL: http://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&oldid=99589405#Decimal_block_bug.3F

Details

Reference
bz8554

Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:30 PM
bzimport set Reference to bz8554.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

In PHP 5.1.4, no non-integer appears to work as expected with time units such as "weeks" or
"minutes". Up to two digits after the decimal point gives 0 Unix time, any further digits
are interpreted as an integer.

Was the installed version of PHP recently updated, perhaps?

Here is what goes on:

The value of the "Other time:" box in Special:Blockip page (a text input named wpBlockOther) is passed to strtotime() to function on line 371 of SpecialBlockip.php (as of revision 27807). It is strtotime() which misinterprets the number indeed. See:

strtotime("2 weeks") returns 1200400424
strtotime("3 weeks") returns 1201005224
strtotime("2.37685 weeks") returns 1613443020

So indeed, this is a bug of PHP's strtotime function (or, if not a bug, it is at least a bad way to use it, because in PHP documentation it is clearly stated that strtotime() expects date to be i GNU format, while "2.37685 weeks" is not in GNU format per http://www.gnu.org/software/tar/manual/html_chapter/tar_7.html).

Anyways, at this is not a MediaWiki bug, I'm marking it as INVALID.

If the behavior of the function is this wildly wrong, perhaps we ought to protect against it -- either by replacing it with our own code or giving a warning on these 'deceptive' inputs.

Confirmed as still occurring as of May 2010. This recently occurred with a global block.

this is a bug of PHP's strtotime function

Nemo_bis: As you set the "upstream" keyword, does an upstream ticket exist?

(In reply to comment #5)

this is a bug of PHP's strtotime function

Nemo_bis: As you set the "upstream" keyword, does an upstream ticket exist?

I didn't check.

Could you just add in this before $expiry = strtotime( $expiry ); which would just cut it off at 2 decimal places.

if (preg_match('/^\d+\.\d{2}(\d+) .*$/', $expiry, $matches)) {
	$expiry = str_replace($matches[1], '', $expiry);
}

It would be ok to "sanitise" the duration if that were produced by MediaWiki (e.g. when one presses "change block"), but as far as I understand here the duration has been entered manually. I don't think it's sane to add exceptions to the specification of blocks duration just for the benefit of one wiki's administrator's jokes.