Yes, that old chestnut! Always a hot topic around the morning tea table. OK, not really but I am sick of that warning in Mahara; a warning for something I cannot fix or something that was not my causing.
Anyhoo, I have posted it to the bug tracker combined with none of my dates displaying (last login, post dates, journal dates, etc.). The bug has been (understandably) triaged with low importance; however,I did get some ideas form the helpful Aaron. I have also found scraps of help online but nothing complete so again I’m sharing my findings in the love for all things open source.
There are in fact two problems with php’s stftime when used in Mahara – %e and %z. %e (day of the month with leading space for single digit) doesn’t work in Windows but can be replaced with %d (day of the month with leading zeros for single digits). %z in Windows displays time zone offset as ‘New Zealand Standard Time’ rather than +1200.
It’s the /lang/en.utf8/langconfig.php file that requires editing however it is good practice to leave the original and make changes to a copy saved in the local directory. Therefore copy the file and save local directory but mimic the files directory structure, i.e. /local/lang/en.utf8/langconfig.php.
Here in lies the first problem. As soon as you upload this file your Mahara site will crash and die (until you fix it) with a fatal error:
It’s an easy fix if your error messages are not hidden. Remove the last two declarations and the function from your /local/lang/en.utf8/langconfig.php file:
Change
$string['strftimedate'] = '%%e %%B %%Y';
to
$string['strftimedate'] = '%%d %%B %%Y';
With the next change there are two options with the problem line:
$string['strftimew3cdatetime'] = '%%Y-%%m-%%dT%%H:%%M:%%S%%z';
The first option is just to remove the %%z, the second option is to hard code a replacement with your UTC offset, for example, +1200 (with no colon). This is my preference (I’ll explain below) but if you live in a country with daylight savings (like me in New Zealand) you will need to update it when daylight savings starts and ends.
I trialled all three options and could not find any reference to the time zone in the database regardless of the %z options I used. Also independent of the changes, the warning will continue to appear as it does its own test on the time zone offset. Once you’ve made the changes you’re happy with you could comment out the offset test from /lib/upgrade.php (but I’m not responsible for your code hacking).
As Aaron suggested I found the time zone offset issue came in to play when exporting a portfolio using Leap2A. The three options and their outputs are below:
the original
$string['strftimew3cdatetime'] = '%%Y-%%m-%%dT%%H:%%M:%%S%%z';
The time zone offset removed
$string['strftimew3cdatetime'] = '%%Y-%%m-%%dT%%H:%%M:%%S';
hardcoding it to +1200 (or +1300 during daylight savings)
$string['strftimew3cdatetime'] = '%%Y-%%m-%%dT%%H:%%M:%%S+1200';
As you can see all have had the string edited to add a colon before the last two characters. The original code has the text-based New Zealand Daylight time (plus additional colon) which I pick would render it flawed when importing into another portfolio (I’ll test it when I have a chance). The same can be said for when removing the %%z, leaving it with an additional colon before the seconds part of the date/time.
So I’m going with hard coding my time zone offset until hopefully the problem is fixed. Tomorrow I try solve the mystery of the disappearing dates.
narissa71's weblog 