Last modified: 2012-08-04 20:49:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16067, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14067 - Invalid timestamp in SpecialContributions.php
Invalid timestamp in SpecialContributions.php
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.13.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.wikivoyage.org/de/User:Hansm
: easy, patch
Depends on:
Blocks: postgres
  Show dependency treegraph
 
Reported: 2008-05-10 10:34 UTC by hansm
Modified: 2012-08-04 20:49 UTC (History)
1 user (show)

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


Attachments
Should fix the bug. Apply to includes/SpecialContributions.php (1.06 KB, patch)
2008-05-10 12:04 UTC, hansm
Details

Description hansm 2008-05-10 10:34:37 UTC
Special:Contributions crashes if a user enters a year or a month for limiting his contribution list. This bug only appears on MW installations with DBs that don't use MW-like integer timestamps, e.g. PostgreSQL.

Problem: includes/SpecialContributions.php produces in invalid timestamp in TS_MW format that is not compatible for SQL queries on DBs that use their own timestamp type.

Added a path.
Comment 1 hansm 2008-05-10 12:04:42 UTC
Created attachment 4892 [details]
Should fix the bug. Apply to includes/SpecialContributions.php

I'm not sure if my first submission has arrived since I can't find my patch in the bug report any more.
Comment 2 Brion Vibber 2008-05-11 00:36:12 UTC
Patch looks wrong offhand; description sounds like it simply is missing a $dbr->timestamp( $ts ) conversion.
Comment 3 hansm 2008-05-11 08:44:05 UTC
@Brion:
Something seems to have gone wrong with the first submission of my patch. That's why I have resubmitted it in comment #1. Do you mean this patch looks wrong? If so, why?

The bug is not only a missing $dbr->timestamp( $ts ), but the fact that the produced timestamp is *invalid*. If you think in TS_MW, the world is simple. MySQL only has to compare integer values, no matter whether a timestamp referes to an existing date/time or not. The problem occures when you want to convert a pseudo timestamp like 20090000000000 into the TS_PG format.
Comment 4 Greg Sabino Mullane 2008-05-11 20:23:58 UTC
Thanks for the report, I applied a modified version of your patch in r34625, and put in some year boundary checks as well. I'm surprised at how gmmktime() handles 0s, which was causing another subtle bug (fixed now, but could pop up in other places that pass a timestamp with a month or day of 0.
Comment 5 hansm 2008-05-11 22:52:42 UTC
(In reply to comment #4)
> Thanks for the report, I applied a modified version of your patch in r34625,
> and put in some year boundary checks as well. I'm surprised at how gmmktime()
> handles 0s, which was causing another subtle bug (fixed now, but could pop up
> in other places that pass a timestamp with a month or day of 0.
> 
Well done. We run MediaWiki on PostgreSQL for about 1/2 year and everything runs fine. So, time format conversion bugs will be rather rare. However, it took 1/2 year until some user has found this one ;-). Anyway, thanks for the bug fix which will make the next version upgrade easier for us.

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


Navigation
Links