I'm running into the same issue described here, error with timezone:
PHP Configuration: It is not safe to rely on the system's timezone settings
I want to have a constructive conversation with my hosting service. So I did some digging on my own, first. This is an Apache server, I am not sure which OS it's on.
My phpinfo() states this:
Loaded Configuration File /usr/local/php53/lib/php.ini
and this, for timezone:
date/time support enabled
"Olson" Timezone Database Version 2013.3
Timezone Database internal
Default timezone America/Chicago
So, at first glance it seems like the timezone is set correctly. Yet I still get the error:
getdate() [function.getdate]: 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 'America/Chicago' for
'CST/-6.0/no DST' instead
I'm anticipating my host telling me "sorry, the setting is correct - please update your application to solve this error".
Do I let them get away with that answer or should I force them to go check the settings in another location that ends in /cli/php.ini ?
I guess I don't understand where that file would be in my case, or why it would even be referenced if phpinfo() says that the only ini file being loaded is at /usr/local/php53/lib/php.ini
Any help understanding this would be very appreciated. I hate talking to my host folks without having a thorough understanding of the issue, myself.
The reason this occurs is because in the 5.3 release, the PHP devs made the decision to require the timezone to be explicitly set in the PHP.ini file (or in .htaccess, or using date_default_timezone_set()). The reason this was done was of a perceived problem with earlier PHP versions where the timezone was not set and people relied on a default which was often not actually correct (eg because they were using a hosted server in a different timezone). There were a large number of serious issues caused by this, and requiring it to be set explicitly was an attempt to resolve these issues.
The solution is to make sure that your PHP.ini file contains a timezone setting. If you're on a shared host and can't update PHP.ini, then you can set it in a local .htaccess file (assuming you are on an Apache server; other server software may differ). And if you can't set it there, then you have to set it in code.
Your host clearly doesn't have the timezone set in PHP.ini. Given that the server is only just being upgraded from PHP 5.2, this isn't surprising; 5.2 didn't require it to be set (it defaulted from the system timezone), so it's easy for it to have been missed in the upgrade.
From your perspective, you can entirely avoid having to have a conversation with your host by setting the timezone in .htaccess. Just create a .htaccess file (or edit your existing one) with the following line:
php_value date.timezone "America/Chicago"
However, ideally it really should be set in the PHP.ini file, and if that's under your hosts control then it would be good for you to raise it with them -- not setting it is a very clear sign that they don't really know anything about PHP, and they certainly haven't actually tested their config after the upgrade. This should worry you, as there could be other issues waiting to bite you because of this; there were some significant changes in PHP between 5.2 and 5.3, a number of features were deprecated and default config values changed, which both you and your host really need to be aware of when doing this upgrade.
Interestingly, the decision to have this timezone warning is actually now in the process of being reversed: with the forthcoming release of PHP 7.0, you will no longer need to explicitly specify the timezone in PHP.ini. You can read more about this change here: https://wiki.php.net/rfc/date.timezone_warning_removal. This obviously won't affect you for now, but it's interesting nonetheless.
While I'm answering, I'd like to re-iterate the paragraph above -- ie the release of PHP7 next month -- and point out that you are upgrading to a PHP version that is already long obsolete.
PHP 5.3 was declared End Of Life over a year ago (August 2014), and has not had any updates since then. Even PHP 5.4 is now end of life (although that has only just happened). I'm really glad to hear that you're moving away from 5.2, but you shouldn't be settling for 5.3: I'd strongly recommend that you upgrade further now, while you're doing the work to upgrade anyway, because otherwise it'll cost you more time in the future.
I'm not suggesting going all the way up to PHP7, but you should consider 5.4 as an absolute minimum, and 5.5 or 5.6 as the preferred versions today. By far the biggest pain of upgrading is from 5.2 to 5.3, so you've already done the hard work; moving up a version or two more would be hardly any extra work now, while you're doing it anyway.