Last modified: 2010-05-15 16:03:14 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 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