Last modified: 2012-11-12 15:41:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8554 - High-precision block times are misinterpreted as time of day and duration
High-precision block times are misinterpreted as time of day and duration
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
unspecified
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
: upstream
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-09 18:40 UTC by ais523
Modified: 2012-11-12 15:41 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description ais523 2007-01-09 18:40:18 UTC
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).
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-10 02:12:19 UTC
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?
Comment 2 Huji 2008-01-01 12:33:58 UTC
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.
Comment 3 Brion Vibber 2008-01-02 18:17:37 UTC
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.
Comment 4 Jesse (Pathoschild) 2010-05-18 23:33:28 UTC
Confirmed as still occurring as of May 2010. This recently occurred with a global block.
Comment 5 Andre Klapper 2012-11-12 15:26:35 UTC
> this is a bug of PHP's strtotime function

Nemo_bis: As you set the "upstream" keyword, does an upstream ticket exist?
Comment 6 Nemo 2012-11-12 15:41:29 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links