PKP Bugzilla – Bug 7567
Time zone warnings
Last modified: 2014-02-14 15:25:01 PST
We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.
I've updated my PHP to 5.3.10 and now I get many large warning messages about not having a time zone set upon every request. There is some discussion about this over here: http://wordpress.org/support/topic/php-530-amp-wp-28-it-is-not-safe-to-rely-on-the-systems-timezone
I'm not sure if we want to set a default timezone (if we do, we can use the configuration parameter asked for in bug 6893) or just direct people to set the timezone setting in their php.ini file (which is commented out by default).
Wouldn't it be best to add a time zone setting to the Website Settings, and let the user select their time zone during installation? During installation we could default to UTC till the user selected a time zone? That would also solve Bug 6894
Unfortunately I think it's worth getting totally comprehensive on this one, given the potential amount of international participation.
- An optional config.inc.php parameter that sets the site-wide default;
- A Journal Setting that allows per-journal (per-press in OMP) override;
Eventually, but not until we've considered it further, we should probably add a user profile setting as well. This would cause users to receive times and dates according to their time zone. But let's leave that final addition until later.
For the journal settings I assume we need to add this setting to 2 places.
Once to the settings wizard while setting up the journal and and in the journal settings page (Management > Settings > Journal).
In both cases the time zone setting doesn't really fit into any of the existing tabs. I suggest to create a new "Time Zone" tab and add a dropdown with the time zones there.
We do have a TimeZoneDAO already which implements a getTimeZones() function which returns a time zone list based on lib/pkp/registry/timeZones.xml.
By the looks of it the TimeZoneDAO isn't used anywhere at the moment. I was thinking about using this time zone list to populate the dropdown but timeZones.xml also contains entries which you usually wouldn't find in a time zone dropdown. I.e.
<entry key="Etc/GMT-3" name="GMT-3"/>
Any suggestions for a standard list? Or would cleaning up timeZones.xml be an option?
Another question would be if the dopdown item should be in the form of America/Halifax or simply list cities. I would suggest going with:
As for the site wide config.inc.php setting. I added a call to date_default_timezone_set() to the constructor of PKPApplication. The logic I implemented will first check if a config variable time_zone is set in config.php, if this is not the case it will fall back to the time zone in php.ini. If this is not set either it will fall back to UTC.
Does this work for everyone?
The TimeZoneDAO is currently used in OCS only. (The master branch of OCS is badly broken, so if you want to see this in action, use the ocs-stable-2_3 branch or a current tarball.) It's used to implement a time zone selection on the user profile form.
Basically, you can alter TimeZoneDAO however you like; the purpose it has in OCS is roughly the same as we want here, so if the list isn't ideal here it isn't ideal there either. You will be breaking OCS, but that's already broken. Feel free to correct the code accordingly in the OCS repository, as it'll likely require a few trivial code modifications, but don't bother trying to test it there. Digging that repo out of the grave will be a big project for later.
Thanks for clarifying. Adding additional tabs in the places mentioned in comment 3 sounds good to you?
I ran into a problem with the context specific time zone settings.
The timezone needs to be specified before we do the first database call because ADOdb makes use of date/time functions. So I added a call to date_default_timezone_set() to the constructor of PKPApplication which uses the time zone setting from config.inc.php, falls back to the php.ini setting if this is not set and then falls back to UTC. So far so good.
I want to change the time zone to the journal specific setting though if the journal has a time zone set. The journals settings are stored in the database though which I cannot access at this point. I also don't think its a good idea set the time zone to the config setting first and then change the time zone again after the context is initialized because this might cause weird side effects. Any suggestions?
After our discussion in the phone conference today it might be best 2 break this down into 2 tasks. The first one, to introduce a time zone config setting which should take care of the issue described in this ticket and the second one to look into having a user specific time zone view which should probably be handled in a different ticket. Sounds good?
Created pull requests here:
I updated registry/timeZones.xml with a list from Ubuntus time zone data file. The existing list contained time zones which are not compatible with date_default_timezone_set().
This has been merged.
Fixes to time zone code