1

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.

Community
  • 1
  • 1
Chris
  • 13
  • 2
  • You mention the CLI. Is that where the error shows up? Often, the CLI and the webserver have different `php.ini` files. – ceejayoz Nov 16 '15 at 15:12
  • This is where my knowledge is lacking. I mentioned CLI only because the other thread I linked (in my question) talked about it. I don't understand what that is or what it does, or if I should be even be asking my hosting service about it. – Chris Nov 16 '15 at 15:14

2 Answers2

0

you need to set your timezone

date_default_timezone_set('Europe/London');

http://php.net/manual/en/function.date-default-timezone-set.php

Roma Rush
  • 4,167
  • 1
  • 18
  • 16
  • This does solve the problem, but I'd definitely have the webhost set a default in `php.ini` rather than doing in in every PHP script. – ceejayoz Nov 16 '15 at 15:11
  • Right. I did add the function call to the application's config.php - which effectively will solve the problem, but I want to understand why the issue is arising in the first place. – Chris Nov 16 '15 at 15:13
0

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.

Simba
  • 4,952
  • 3
  • 19
  • 29
  • Thanks...I *might* be able to go to 5.4 but the shopping cart system I'm on fails with 5.5 for some reason. Unless I can re-mediate the cart PHP code myself for the 5.4 to 5.5 jump, I will be stuck at 5.4 for a very long time. – Chris Nov 16 '15 at 17:26
  • Also, my phpinfo() seems to show that the default *is* set...so I still don't understand why I am even getting this error (see my original post/question up above...) – Chris Nov 16 '15 at 17:46
  • Re the code failing on 5.5... this shouldn't be a big deal; the compatibility breaks between 5.4 and 5.5 were really minor (see http://php.net/migration55), so it should be reasonably easy to locate the problem. (You don't want to be stuck a fixed PHP version forever, regardless of which version it is... and the longer you leave it, the harder it is to upgrade subsequently -- as you're discovering now) – Simba Nov 17 '15 at 13:37
  • Re the default is set: Well, PHP 5.3 will still pick up the default from the OS even if it isn't set in php.ini, just like PHP 5.2 used to, so from that perspective nothing has changed. The difference is that 5.3 now issues a warning message. Apart from the message, the functionality is identical, so you will still see that the default is set because it is set. – Simba Nov 17 '15 at 13:39
  • Thank you for the excellent analysis/advice, Simba. I'm at 5.3 now and yes I will focus on getting to 5.5, asap. – Chris Nov 18 '15 at 13:41