Closed julesbl closed 8 years ago
This is a PHP configuration issue, not a CI one.
And to bad to those people who don't have access to php.ini, why bother with the config option at all?
If you don't have access to php.ini, then it's your sysadmin's fault.
Have you used some of the shared hosting out there? Lucky to be able to get the files up to the server let alone be able to alter php.ini
Have you tried telling the hosting provider that they suck? :)
Again, if you don't have access to the php.ini, it's their fault. They have the responsibility to give you a properly-configured environment.
They have people in charge of their system who don't care about the opinions or needs of other people and who just ignore anybody else’s opinions and reply saying it your fault and you should fix it, they know they are right :)
Well, it's a two-way street - I am in charge here and I don't care about crappy hosting providers. :)
It's a free market - if they provide a bad service, they'll lose customers. It's not CodeIgniter's job to protect their business.
That's true, would be nice if they have not set it to do something about it.
Would also mean that the error log would use the same time zone as that which the rest of the site is running in.
The time_reference
setting in the config file is only used by the date helper, and the only part of CI that uses the date helper is the Calendar library. The comment in the config file implies this:
See the 'date helper' page of the user guide for information regarding date handling.
...but the sentence before that implies a broader use in the system, which isn't the case:
This preference tells the system whether to use your server's local time as the master 'now' reference, or convert it to the configured one timezone.
(I guess the "one" should be removed from that sentence.)
Personally, I avoid using the date helper because it creates discrepancies between the times generated by the date helper and those in the logs (since log_message()
doesn't use the date helper or the time_reference
setting).
The best thing to do if you can't modify the php.ini is to set the value yourself in your index.php file. The following is an example of this (though probably overly-aggressive in checking the existence of the value and functions): https://github.com/ci-bonfire/Bonfire/blob/develop/public/index.php#L100
Since you're seeing the notices in your logs, you could probably get away with something simpler, like:
if (ini_get('date.timezone') == '') {
date_default_timezone_set('UTC');
}
Then you would just replace 'UTC' with whatever timezone you wanted. If you're really stuck on using the config value, you would need to call the function later, after the config file has been loaded, which means there's still a chance that something would attempt to use the default timezone before it is set.
A pre_system
hook could set the timezone, but I'm not 100% sure that PHP's microtime()
is independent of the default timezone setting; the Benchmark class uses microtime()
to set the total_execution_time_start
and loading_time:_base_classes_start
benchmarks before the Hooks class is loaded.
Yes, microtime()
(and time()
too) is independent from date.timezone - UNIX timestamps don't have a timezone.
I am using a separate file that I keep within config/ directory for php ini settings, but on modified CodeIgniter. Here is an example what it contains:
<?php defined('BASEPATH') OR exit('No direct script access allowed');
/*
*---------------------------------------------------------------
* PHP ini settings
*---------------------------------------------------------------
*/
@date_default_timezone_set('Europe/Sofia');
ini_set('memory_limit', '512M'); // Quite extreme value.
ini_set('post_max_size', '16M');
ini_set('upload_max_filesize', '16M');
ini_set('max_file_uploads', 20);
ini_set('max_input_time', 60);
ini_set('auto_detect_line_endings', true);
if (IS_CLI) {
ini_set('max_execution_time', 0);
ini_set('html_errors', 0);
ini_set('error_prepend_string', '');
ini_set('error_append_string', '');
ignore_user_abort(true);
} else {
ini_set('max_execution_time', 300);
// http://www.controlstyle.com/articles/programming/text/if-mod-since-php/
session_cache_limiter('private_no_expire');
}
ini_set('pcre.backtrack_limit', 10000000);
Such a configuration file is more convenient for me than tweaking index.php, because in my applications I have separate index.php files for the front-end and the admin panel.
Do you like this approach with additional configuration file?
Not a bad idea, just add it to the autoload and you're away, wont work for all php configurations but an improvment
Let us say it will contain only @date_default_timezone_set('xxxxxx/xxxxxx'); other settings will be added by a user-developer whenever it is necessary.
Sounds good, commented out on first install
Ok, can we stop this now? This isn't a chatroom.
Hi
Developing a site using codeigniter 3.04 under php 5.6.
Enabled the logging and put it to 4 just to see if it was working.
After I had fixed the server configuration problems I was surprised to start getting
Warning: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /vendor/codeigniter/framework/system/core/Log.php on line 176
I have added date_default_timezone_set('Europe/London'); which fixed this but had I set the same time zone in the config.php file $config['time_reference'] = 'Europe/London';
Perhaps this could be one of the first things Codeigniter.php does once it successfully loads the configuration?
Jules