Issue:Year system is not compatible with MW 1.15
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 / answered |
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 theLanguage
-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)