Installer warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings

Same here using fresh checkout of head, using standard install profile. I skipped over the timezone settings, i.e. leaving them unchanged.

Still present in head. Bumping to major because it ruins the first time experience with a very very long error message.

Yeah, I broke this when we moved the per-user timezone into AccountProxy::setAccount(). We need to add a check and set the site-wide default earlier and also during installer, somehow.

And with the latest code it is not possible any more to install with drush, after the install the system only shows a fatal error page with the above error message.

An install via the UI works with the afore mentioned errors but the installation works after reload.

According to date_default_timezone_get, this warning is only output in PHP < 5.4.0. Drupal 8 requires PHP 5.4.5, so this warning is the least of your problems.

I vote that we close this issue.

No, it is the other way round. This message is printed *since* 5.4, when you don't have it in php.ini.

If it is not safe to rely on the system's timezone settings then let's explicitly set the default timezone to UTC in the installer. That is what date_default_timezone_get would return at this stage even if we were to suppress the warning.

OK. My bad. Since I run Ubuntu, it seems I can't see this warning in 5.4+, even when I don't set it in php.ini. That's the part that confused me.

Since the problem is the warning, and it's slightly better to use the setting in php.ini, what about this solution? It maintains the current code, but wraps the call with the '@' error-control operator, which prevents the warning being thrown, and according to the docs will eventually default to 'UTC', if not defined in php.ini.

Here's an update to patch in #9. I forgot to take the php.ini setting into account.

Tested on PHP 5.5.20

@mducharme: IMHO this is worse than #9. In Debian/Ubuntu, date_default_timezone_get() will return the proper timezone, but ini_get('date.timezone') is empty. In all other cases, date_default_timezone_get() will also return 'UTC' (and a warning). The '@' gets rid of the warning without trying to guess the internals of that function.

I'm reuploading #9.

Is it possible to move this error to the site status report? I think it would be nicer than pushing it on the user.

The issue with using the @ symbol is that you are suppressing all warnings and errors that may come from this function call. I don't think that's a good solution under any circumstance since legitimate errors would be suppressed as well.

Does that mean we can not fix this in a way that we don't have to report an error?
If the error has to be reported, then yes, moving it to the status report seems like the way to go.

On my installation, where I do get this error:
1. Fresh install of head
2. Complete installation (with getting the error discussed here
3. From the default /node page you get to on succesful install, *having done nothing else*, I logout
4. I get an error screen with the same timezone error. Can't login anymore.

That's borderline critical, no?

@LewisNyman: it's a PHP-created warning. It would be possible to move it to the status report, but we'd need to create our own error handler to intercept and forward the error. Way too much trouble for this.

@mducharme: true that all other errors would be suppressed. It's not a perfect solution. Your way, we get rid of functionality in order to not get a warning. My way, we get rid of the warning (and all the zero errors/exceptions, at least according to the docs), but we keep the functionality. Both choices are viable. I just prefer mine, but I understand your preference for yours.

@yoroy: This fix is just for the installer. Drupal should have set the default timezone correctly using whatever you chose in the installer. The error you're get is indeed more serious, but it's already the subject of #2475001: Cache DateTime exception when Timezone not set.

I don't think either patches are good enough as is. I was just trying to get the ball rolling. I like the idea of a custom handler, logging the warning in dblog. I think adding it to the status report is overkill.

A custom handler to log a warning on dblog stemming from the inability to get a default value for a drop-down selector in the installation process? Really? You know how many times I looked at the dblog to understand what happened during install? Never happened.

And what should be logged? "Default value set to UTC". It doesn't add anything to what really matters, which is which value was really set during this step.

The objective is to get rid of the warning. So let's do it, without getting rid of the functionality.

@LewisNyman What about a pre-installation requirement?

It appears to me to make sense to do a date_default_timezone_set() given the point at which this becomes visible to the user, i.e., at the top of the site configuration form right *before* the person installing Drupal is about to get the opportunity to select a time zone. If Drupal assigns its own default timezone default to this one form field, the user can change it right away.

I would argue the cleanest way would be to declare unilaterally that the default Drupal value for the default timezone field in this form is UTC, since the user is right at the point where they can override that. In other words use mducharme's solution in #8.

The attached code introduces a new variable that first is set to UTC, then is set to the PHP default if one exists. This is in hopes of accommodating all the above commenters' objections. But it is extra variable baggage. I believe it would be much cleaner to set a "Drupal default" UTC.

I understand that people who have already set their PHP default timezones would prefer them to be respected, but I think the most urgent issue here is preventing a big screen-filling red error message from becoming the first Drupal experience of the first-time Drupal 8 user.

Does this patch create watchdog messages with the wrong time zone during some phases of install?

Probably. I bet it also annoys kittens in its spare time. This is why mducharme's solution up in #8 is a better idea.

#8 seems a hardcoded workaround that would confuse us later.

Attached is a patch to expose more information regarding this warning to the 'Site report' page.

I just came across this in another duplicate issue.

I am a little confused as to what we are doing. It sounds like we are attempting to set the timezone before the install form for setting the timezone without checking that the php.ini time zone is set.

I am testing this patch.

Tested and it needs work. I do no think that having that set in php.ini should be required to run Drupal.

Now that #2475001 has been resolved, it isn't even an issue to run Drupal out of the box.

I am in the boat that we should write a custom handler for this error. However, I am not sure that it is really 100% necessary for this one issue.

My solution is to use the patch from the other issue #2489434 but also add a note to the status page that the system timezone should be set in the system module.

Okay so I did a few things with this patch.

• I set the default timezone in the install script.
• I added a hook_requirements implementation so that the user knows to fix the issue
• I added a spot in the default.settings.php so that this can be set site-wide there if need be.

My motivations with this approach is that we should be out of the users way upon install as much as possible.

I reinstalled d8 now that #2475001: Cache DateTime exception when Timezone not set is in. It looks like this error also prevents succesful login after installation. I end up on the Welcome to My Site page, but not logged in.

Has this been fixed by #2475001: Cache DateTime exception when Timezone not set?

@frob: Nice patch, but that is really overkill. Drupal core should do 2 things:
1. Show a sensible default timezone to the user on install (see #9).
2. Save the timezone defined by the user, and use that from then on, and not care at all what (if any) is defined in php.ini.

All you're doing is telling the user that they need to set this value in php.ini, when it really should not matter at all if they do or not. If they don't the default 'UTC' is also fine. They can setup whatever they want at install time. According to the docs for date_default_timezone_get(), Drupal should make sure to do a date_default_timezone_set() early on in the bootstrap using the value set by the user.

@yoroy: not sure if you should be logged in after install.

@cilefen: no. this is a warning thrown up on the install page. The other is an error thrown up by the page_cache module.

@cilefen: No, that's why I posted, I updated my d8 after that fix got in and reinstalled. Not logged in after succesful install.

@jcnventura: you should definitely be logged in after install, that's how it has always worked. You can verify this on simplytest.me.

@jcnventura: So then should we just set the timezone based on what the user has set in boot.

Something like this:

$default_timezone = (!empty($default_from_user) ? $default_from_user : 'UTC';
date_default_timezone_set($default_timezone);

Where in boot should this happen? Also, this happens on the last screen of install, before Drupal's boot takes over.

It sounds like my initial patch from #27 (that I brought over from the other issue) should solve the problem for install.php. Does the problem exist in the normal Drupal boot?

@frob, the thing is that I believe Drupal already does this.. You should be seeing warnings everywhere, if it weren't. I'm not sure why page_cache managed to bypass that, but the rest of Drupal seems to be using a date_default_timezone_set() somewhere.

This is why I keep pointing people back to #9. The problem in this issue is really simple. On the install page we need to set a default value. Once the user (or drush) sets the site's default timezone using that value or something of their choosing, that value will take effect, and the code used in this patch becomes irrelevant. It's why I believe that status report or installation requirement warnings (#25 or #29) or even logs to the database are irrelevant. It's all about a simple default value in the install form. If someone doesn't like what I suggested in #9 (hiding the warning, while keeping the Debian-specific logic intact), then let's go with #8 and simply set it to 'UTC' by default. Note that #21 is completely equivalent to #9, with a superfluous variable assignment.

@jcnventura I completely agree with what you're saying. My patch from #27 just sets the default to UTC for the whole install system.

What I have done with this new patch is reroll the patch from #9 --only instead of suppressing errors, I just set the value to 'UTC'. The default value of this form doesn't matter at all because as soon as the page loads js changes this to what ever the user client timezone is. This default value is superfluous.

While it would be nice to figure out a good solution, I think explicitly setting UTC is good enough for now (my patch in #8 does this) so that we can all move on to higher priority items. We can create a low priority follow-up task to get detection working later.

Yes, either commit #8 (default is always UTC), or #9 (default is what is configured in php.ini, or if that fails UTC and hiding the warning). We have 16 followers in this thread, somebody vote for one of them and mark this RTBC, please.

In case anyone is wandering whether to mark it 'needs work', consider the following: this is to set the default value of a drop-down in the installer form. And in that light, and in support of #9, hiding the warning should be completely harmless (and according to the documentation, the case we want to ignore is the only error or warning raised by that function).

Let see if this retest will work. If not then I will test manually and mark RTBC tonight.

Nevermind, I see that it passed the test now.

RTBC ++ patch from #8

Let us remember as well that this value is changed as soon as the page loads.

I prefer #9 here. Suppressing warnings is usually not good, but in this case it's literally a single call to the function and it's well commented.

Committed/pushed #9 to 8.0.x, thanks!

The problem is bigger than this, see #2510150: AccountProxy is not calling date_set_default_timezone() for anonymous users. That should likely also fix the error during the installer, then we can revert this.