Now with the newborn elefant PHP 7 in the herd, there is a lift on the date timezone settings warning: it has just been removed. That means, it’s now that you need to take care in the server’s configuration that the proper default timezone value is set, otherwise it will fall-back to UTC with no more reminder spamming the log-files or screen. Alternatively, you can make use of the date_default_timezone_set() function within your application to configure the default value.
Apart from the fall-back to UTC, it was not always that way: error messages about an unconfigured time-zone setting when a date or time function is called were introduced with PHP 5.1.0 (Nov 2005) giving notice that PHP is not configured properly.
It was either an E_NOTICE or an E_WARNING depending on the severity (notice on an invalid timezone value and warning if one of the TZ environment variables was used to set it automatically – E_STRICT was possible as well on a flowery mixture of diverse conditions):
It is not safe to rely on the system’s timezone settings. Please use the date.timezone setting, the TZ environment variable 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.
Which is what that (from PHP 5.2 quoted) timezone error message reflects.
To Please or To Tease
It was then with PHP 5.3 (Jun 2009) that the tone got rougher. From a more charming please, it was now required enclosed in asterisks to even more point with the finger that something was missing (#fb183b1; Jan 2009). But pushing that hard for years couldn’t make it, the years went by until in January 2015 Bob Weinand took the intiative with PHP RFC: Remove the date.timezone warning to remove the configuration warning from PHP. In the related internals discussion (Grokbase) you can find pros and cons in quite some civic tones but also opinion pieces for example from the this warning message introducing developer (“absolutely not.”).
As PHP 7 gave the possibility to make deeper changes and the vote on the RFC went for the proposal; finally with the release of PHP 7.0.0 (Nov 2015) the warning is gone (#b22caa8):
Previously, a warning was emitted if the date.timezone INI setting had not been set prior to using any date- or time-based functions. Now, this warning has been removed (with date.timezone still defaulting to UTC).
As you can see this ini-setting and it’s paired warning has quite some history. Which story does it tell? Perhaps this one: If you require something you should really mean it that way. E.g. instead of an error message PHP should have come to an halt on startup if the ini-setting was missing (and no, don’t guess with TZ environment if you really have a requirement, such is prone to error and unsurprisingly it did invite flaws in the fallback routines as environment variables in the TZ context are not that stable). Just giving words about a requirement does not make it one and users are left with error messages they do not understand, they do not even look-up the description of the ini-setting within the ini or the PHP manual.
So I try to take on it lightly: As with the many other settings that are to be configured (and more important than this one), the change in PHP 7 to remove the timezone error messages streamlines PHP usage. As with any new release, diff the default configuration file boilerplates to learn about changes. The file is very well documented with comments. Also support your favorite package manager who takes care so often about all these little details for us all.
Still there rests a bigger story behind this warning as it is so exemplary. I for myself can well live with seeing this warning disappeared. Understanding distributed systems and applications within those is a higher skilled job, not every PHP developer can cope with configuring such systems – and does not even need to. For a beginner this setting was just too complicated to configure and I can see many users were puzzled just by the error message. Albeit the fallback was made for them. So then why warn? Don’t you trust the fallback perhaps? I leave it to the educated reader to comment on this.