Issue:Year system is not compatible with MW 1.15

From FollowTheScore
Jump to: navigation, search
Description: When displaying dates with addfirstcategorydate= with DPL v1.8.3 and MW 1.15, the day, months and hours are OK, but the year is always 1979.
Extension / Version: DPL   /   v1.8.3 with MW 1.15
Type / Status: Bug   /   closed

Problem

Description says it all! Thank you for this great update I love your extension my site completely relies on that to manage all the emulators (emuwiki.com).


Reply

Does it work if you set the timezone difference in the preferences dialogue of a user who is logged in? Gero 07:22, 14 June 2009 (UTC)

No, changing any date setting such as format preference and timezone difference did not work. Also I had not seen this but it seems the seconds are not displayed at all. You can test and change anything you want in the DPL invocation here if it can help you. EmuWikiAdmin- 14:19, 14 June 2009 (UTC)
I have the same problem, too. When I'm not logged in, the date and time are displayed in UTC. Eg. at this site http://www.thomas-krenn.com/de/wiki/Benutzer:Wfischer/Statistik/Quartal the first entry has "2009-03-12 19:28:". When I'm logged in as "Wfischer" in our wiki this entry has the following date/time: "1979-03-13 20:28:" (so a difference of nearly 30 years - if I'm right the difference is 25 hours less than 30 years). fyi: I have nothing set in the timezone difference in the user settings. When I set something there, the first entry shows "2009-03-12 21:28:" (which is the correct time in CET). So the whole thing is no problem for me, but perhaps my experience helps somehow. btw: seconds aren't displayed in this DPL results in our wiki, too. --Wfischer 07:28, 15 June 2009 (UTC)

Reply

Regarding the missing seconds: Currently the default is to show hours and minutes only. You can change this via 'userdateformat=Y-m-d H:i:s'. I will change the default as well so that seconds will be shown in future.

The 30 years of difference are quite funny. But it is much less fun to find the difference between older MW releases and newer ones so that DPL can eventually work with both ...

Has anyone observed a problem with date/time (apart from UTC / non-UTC) in the more recent MW releases like 1.13, 1.14 ?

Gero 12:02, 15 June 2009 (UTC)


I had been running the same DPL invocations with 1.13 and 1.14 with no problem at all (using the default display with no userdateformat). All this happened when I installed simultaneously DPL v1.8.3 and MediaWiki v1.15. The weird thing is that MediaWiki does not mention anything in their release note about any change in the date format. I'll try to compare my old database and the new one and come back with what might be different. EmuWikiAdmin- 14:38, 15 June 2009 (UTC)
I found an old MW 1.7 installation on my PC and I made a change which seems to work with that version. So I suggest that you download DPL 1.8.4 and hopefully everything works fine. Gero 18:44, 15 June 2009 (UTC)
Great!!! Problem solved for me! EmuWikiAdmin- 20:57, 15 June 2009 (UTC)
Hi Gero, have just tried the newest version of DPL (1.8.4) on MW1.14 an run into the same problem with DATE-formatting. First I thought, that it has something to do with the sysop status of the user, because if not logged in or logged in as regular user, the display was fine, as sysop the year shows as 1979. But now, it ist wrong in any case. I changed the language- , dateformat and timezone settings, but could not get back the state, where it was working correct. May be, there is some caching-problem, even if I tried to turn caching off for the testpage. I will continue experimenting tomorrow. Grüße aus Bayern nach Hessen, Biowikiadm 14:32, 16 June 2009 (UTC)
How nice, Bayreuth is very close to my hometown (Pegnitz) :-)
When I call your page everything looks fine. Did you try to add &action=purge to the URL? -- Gero 16:08, 16 June 2009 (UTC)
Thanks for the fast response. I tried the purge, but it does not allways help. Its really very strange. Some user sees 1979 mainly if logged in, ... irrelevant stuff deleted ... see below.
BTW, my hometown is Berlin, where you are working now, if i'm not wrong. So greetings to the capital! Biowikiadm 18:17, 16 June 2009 (UTC)

Cause of Problem detected

Me again, Biowikiadm 14:04, 17 June 2009 (UTC) I have done a litle bit of debugging and found the reason for the problem. It occurs, probably from MW1.14 upwards, if a user saves its preferences for the first time.

  • A fresh created Account does not contain an entry for the "timecorrection" - field.
  • After saving the prefs, the field appears with a defaultsetting of "System|" (other "|" or ":" delimited stuff is possible), see class Language::userAdjust() in languages/Language.php , which seems to be responsible to deal with this option.
  • Method DPLMain::getTimeCorrection() gets a bit messed up with this kind of value...
  • I dont know, how to solve this best, there are many methods to return date and/or time-strings based on timestamp-strings in the Language-class which take such corrections into account. Maybe its easyer to use methods from $wgLang directly instead of doing work twice.
  • As far as i could see, there are only two places in DPL, where $timecorrection is used, I have changed them as follows:
line: in file DPLMain.php
0019:   global $wgUser, $wgLang, $wgContLang, $wgRequest, $wgRawHtml; // $wgLang added
0313:   // $timeCorrection = self::getTimeCorrection($wgUser); // can be removed
1358:   //		$date = date('YmdHis',strtotime($date)-$timeCorrection); // changed to:
1358:			$date = $wgLang->userAdjust($date);
2547:   // 		$dplArticle->mDate= date('YmdHis',strtotime($dplArticle->mDate)-$timeCorrection);
2547:			$dplArticle->mDate= $wgLang->userAdjust($dplArticle->mDate);
2832: ..	private static function getTimeCorrection($user) { // function could be removed.

The $wgLang->userAdjust() method exists at least from MW 1.8.2. But I've tested it only on MW 1.14.2. One Advantage of this solution: It uses the same semantics like e.g. skins to show the "last modified date" and one can hope, that it stays compatible with upcomming MW versions, in case they invent new formats to appear in this Useroptionfield. Greetings --Biowikiadm 11:23, 18 June 2009 (UTC)

Thank You ...

for finding out how to reuse existing code. It is of course much better to use an existing function. The problem in this case was that 'userAdjust' is not really the kind of name I had been looking for. 'AdjustUserDate' or something like that would have been a better name, I think.

Anyway, I will adopt your finding for the next release! Gero 04:58, 19 June 2009 (UTC)

Es freut mich, wenn ich helfen konnte, Dank gebührt aber vor allem Ihnen für die Arbeit und Zeit, die in der Entwicklung von DPL stecken! Ein super Tool. Das wollte ich mal loswerden und sorry, das ich es in Deutsch tue, aber mein Umgangsenglisch ist nicht so toll. Viele Grüße, --Biowikiadm 13:50, 19 June 2009 (UTC)