Last modified: 2011-03-21 17:47:23 UTC
If setting a time field using {{{field|Timestamp|input type=datetime|mandatory|default=now}}} the time set will be timezone independent. It's behaving as coded, since the time() function returns UTC time, but it doesn't seem to be behaving as intended, given that one of the first operations performed in the SF 'now' handling code is to get the local timezone.
Created attachment 8108 [details] Fix so that 'now' uses the wiki local timezone. This patch fixes the 'now' not honouring the wiki set timezone by ensuring that all uses of the date() function wrapped between calls to date_default_timezone_set( $wgLocaltimezone ) and a reset to whatever the local TZ was set to. (Using date_default_timezone_set seems to be more reliable than putenv; it's what mediawiki itself does for timestamping.) Works well for me with a couple of cavaets: 1) Due to the subclassing used, it's possible for the time part being one second to midnight and the date part being the day at midnight if the call to time() in the DateTime's 'now' section happens just before the second tick, and the call to the parent class happens just after. A rare problem, but it does suggest that processing the date/time into a data structure should happen outside transforming it into form components, which is probably a good idea anyway. 2) The code for processing a datetime with str2time is untouched and needs to set the specified timezone for the time translations not to munge the output, I think. Hard to test, as SMW Date types don't like the timezones I've set. Also, minor tweak: the timezone box is now size="3" to fit the likes of NZDT :-)
Hi John, Thanks for this awesome patch! I finally got the chance to look at it today, and I just checked it in (with some small modifications). It seems like it's working for me, but please try out the new version of the code when you can (assuming you use SVN), and feel free to re-open this bug if there are any problems. Setting this to "fixed".
I'm on postgresql and I'm getting this output, using svn trunk: A database error has occurred Query: UPDATE page SET page_touched = '11012' WHERE page_namespace = '120' AND page_title = 'March_2009' Function: SMWStore::updateData Error: 1 ERROR: invalid input syntax for type timestamp with time zone: "11012" I guess there may have been a schema change since 1.5.5.1, but until #26202 is resolved, I'm a bit stuck :-/
Bug still here A database error has occurred Query: UPDATE page SET page_touched = '11012' WHERE page_namespace = '0' AND page_title = 'PPA' Function: SMWStore::updateData Error: 1 ERROR: invalid input syntax for type timestamp with time zone: "11012" LINE 1: ...re::updateData XVilka */ page SET page_touched = '11012' WH... ^ Backtrace: #0 /usr/home/droid-dev/www/includes/db/Database.php(538): DatabasePostgres->reportQueryError('ERROR: invalid...', 1, 'UPDATE page SE...', 'SMWStore::updat...', false) #1 /usr/home/droid-dev/www/includes/db/Database.php(1212): DatabaseBase->query('UPDATE page SE...', 'SMWStore::updat...') #2 /usr/home/droid-dev/www/extensions/SemanticMediaWiki/includes/storage/SMW_Store.php(238): DatabaseBase->update('page', Array, Array, 'SMWStore::updat...') #3 /usr/home/droid-dev/www/extensions/SemanticMediaWiki/includes/SMW_ParseData.php(252): SMWStore->updateData(Object(SMWSemanticData)) #4 /usr/home/droid-dev/www/extensions/SemanticMediaWiki/includes/SMW_ParseData.php(406): SMWParseData::storeData(Object(ParserOutput), Object(Title), true) #5 [internal function]: SMWParseData::onLinksUpdateConstructed(Object(LinksUpdate)) #6 /usr/home/droid-dev/www/includes/Hooks.php(133): call_user_func_array(Array, Array) #7 /usr/home/droid-dev/www/includes/LinksUpdate.php(72): wfRunHooks('LinksUpdateCons...', Array) #8 /usr/home/droid-dev/www/includes/Article.php(3317): LinksUpdate->LinksUpdate(Object(Title), Object(ParserOutput)) #9 /usr/home/droid-dev/www/includes/Article.php(2081): Article->editUpdates('== Primary Prot...', 'Created page wi...', true, '20110227174448', '953', true) #10 /usr/home/droid-dev/www/includes/Article.php(1764): Article->doEdit('== Primary Prot...', '', 101) #11 /usr/home/droid-dev/www/includes/EditPage.php(900): Article->insertNewArticle('== Primary Prot...', '', true, false, false, false, false) #12 /usr/home/droid-dev/www/includes/EditPage.php(2552): EditPage->internalAttemptSave(false, false) #13 /usr/home/droid-dev/www/includes/EditPage.php(389): EditPage->attemptSave() #14 /usr/home/droid-dev/www/includes/EditPage.php(271): EditPage->edit() #15 /usr/home/droid-dev/www/extensions/FCKeditor/FCKeditor.body.php(159): EditPage->submit() #16 [internal function]: FCKeditor_MediaWiki->onCustomEditor(Object(Article), Object(User)) #17 /usr/home/droid-dev/www/includes/Hooks.php(133): call_user_func_array(Array, Array) #18 /usr/home/droid-dev/www/includes/Wiki.php(545): wfRunHooks('CustomEditor', Array) #19 /usr/home/droid-dev/www/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest)) #20 /usr/home/droid-dev/www/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest)) #21 {main}
Setting back to "fixed" - this new bug report is totally unrelated.
