Last modified: 2010-05-15 16:03:14 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 T16764, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14764 - r37158 introduces MySQL specific code
r37158 introduces MySQL specific code
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.13.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-09 05:57 UTC by OverlordQ
Modified: 2010-05-15 16:03 UTC (History)
1 user (show)

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


Attachments
Patch to Skin.php (550 bytes, patch)
2008-07-09 05:57 UTC, OverlordQ
Details

Description OverlordQ 2008-07-09 05:57:28 UTC
Created attachment 5060 [details]
Patch to Skin.php

In r37158 Skin.php is changed so that lastModified will either return a date based on a specific revid or a given article.  This is all fine an dandy, but the value this function returns is sent to Language::sprintfDate which unfortunately expects a certain input.

Before r37158 the only call was to $wgArticle->getTimestamp which pulled the timestamp and formatted it with TS_MW (YYYYMMDDHHMMSS).  Unfortunately the added code polls and returns directly from the database.  This is fine with MySQL as the timestamp is stored as a string in TS_MW format.  With other DBs which store as a proper timestamp data types what it returns can vary.  With PG's case:

Before: 20080703043819
After: 2008-07-03 04:38:19+00 

Since sprintfDate expects TS_MW the substr inside the function will fail in odd ways when it tries to parse -0 as a month.

So the return from Revision::getTimestampFromId needs wrapped and formatted to the expected format.
Comment 1 Chad H. 2008-07-09 12:28:15 UTC
Applied in r37385
Comment 2 Brion Vibber 2008-07-09 19:21:11 UTC
That fix was in the wrong place; moved the format normalization to the backend where it belongs in r37419.

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


Navigation
Links