Difference between revisions of "Issue:Year system is not compatible with MW 1.15"

From FollowTheScore
Jump to: navigation, search
(Reply)
Line 43: Line 43:
 
:::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, but sometimes also if not logged in. There is a testaccount demotest:d3m0t3st with read-access to the demo-area, but in the moment the page looks right there. I will try to give it full access to the page tomorrow but unfortunately I have just found, that my ACL-system doesnt work anymore. For now is "Feierabend".
 
:::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, but sometimes also if not logged in. There is a testaccount demotest:d3m0t3st with read-access to the demo-area, but in the moment the page looks right there. I will try to give it full access to the page tomorrow but unfortunately I have just found, that my ACL-system doesnt work anymore. For now is "Feierabend".
 
:::BTW, my hometown is Berlin, where you are working now, if i'm not wrong. So greetings to the capital! [[User:Biowikiadm|Biowikiadm]] 18:17, 16 June 2009 (UTC)
 
:::BTW, my hometown is Berlin, where you are working now, if i'm not wrong. So greetings to the capital! [[User:Biowikiadm|Biowikiadm]] 18:17, 16 June 2009 (UTC)
 +
 +
== Cause of Problem detected ==
 +
Me again, [[User:Biowikiadm|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 <code>class Language::userAdjust() in languages/Language.php</code> , which seems to be responsible to deal with this option.
 +
* Method <code>DPLMain::getTimeCorrection()</code> 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 <code>timestamp</code>-strings in the <code>Language</code>-class which take such corrections into account. Maybe its easyer to use methods from <code>$wgLang</code> directly instead of doing work twice.
 +
* Meanwhile I have simply disabled <code>DPLMain::getTimeCorrection()</code> as a temporary solution.
 +
<pre>
 +
line: in file DPLMain.php
 +
2832: private static function getTimeCorrection($user) {
 +
2833+ return -7200;  // TK 17062009 line inserted as temp. patch
 +
</pre>

Revision as of 16:04, 17 June 2009

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, but sometimes also if not logged in. There is a testaccount demotest:d3m0t3st with read-access to the demo-area, but in the moment the page looks right there. I will try to give it full access to the page tomorrow but unfortunately I have just found, that my ACL-system doesnt work anymore. For now is "Feierabend".
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.
  • Meanwhile I have simply disabled DPLMain::getTimeCorrection() as a temporary solution.
line: in file DPLMain.php
2832:	private static function getTimeCorrection($user) {
2833+		return -7200;   // TK 17062009 line inserted as temp. patch