I'm getting the following error messages when I run update.php (updating from 6.20)

* Warning: Cannot modify header information - headers already sent by (output started at /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc:2068) in drupal_send_headers() (line 1044 of /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc).
* Notice: date_default_timezone_set() [function.date-default-timezone-set]: Timezone ID '-14400' is invalid in drupal_session_initialize() (line 262 of /home/content/p/w/a/pwarwick/html/includes/session.inc).
* Notice: date_default_timezone_set() [function.date-default-timezone-set]: Timezone ID '-14400' is invalid in drupal_session_initialize() (line 262 of /home/content/p/w/a/pwarwick/html/includes/session.inc).

The first message is new ... on previous executions of update.php (which also failed) I got the timezone messages. On this attempt I get the extra message.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Patricia_W’s picture

I investigated the timezone problem and for user 1 in the Users table the timezone is (as noted above) -14400. Presumably this was valid for Drupal 6 but is not now. It is a varchar(8) variable so I could not change it to something like America/Toronto. I modified bootstrap.inc to hardcode the variable to "America/Toronto" and I do not get that error again.
Now, when I run update.php the first time I get a blank page, the second time I get:
* Warning: Cannot modify header information - headers already sent by (output started at /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc:2070) in drupal_send_headers() (line 1044 of /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc).
* Warning: Cannot modify header information - headers already sent by (output started at /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc:2070) in install_goto() (line 1046 of /home/content/p/w/a/pwarwick/html/includes/install.inc).
* Warning: Cannot modify header information - headers already sent by (output started at /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc:2070) in install_goto() (line 1047 of /home/content/p/w/a/pwarwick/html/includes/install.inc).

TallDavid’s picture

Title: Update.php error messages » Update.php warning/notice messages

I'm also getting this notice on a site being upgraded from 6.19=>7.0-rc3:

Notice: date_default_timezone_set() [function.date-default-timezone-set]: Timezone ID '-21600' is invalid in drupal_session_initialize() (line 262 of .../includes/session.inc).

  • Since it's a Notice, I'm assuming that it can be safely ignored.
  • Is there something that can be done in the pre-upgrade stage on the Drupal 6.x site to avoid these messages?
  • If so, should changes be made to the upgrade documentation?

Note to self: aft.c

coltrane’s picture

Title: Update.php warning/notice messages » Upgrade to 7 glaring timezone invalid notice
FileSize
74.2 KB

Also experiencing this ugly message when upgrading.

I wonder if suppression is adequate. Note, this notice was mentioned in #785184: Attempts to update a D6.16 site to D7

coltrane’s picture

Category: support » bug
FileSize
693 bytes

Here's a patch which checks if the maintenance mode is in update before trying to get the user's timezone.

coltrane’s picture

Version: 7.0-rc3 » 7.x-dev
Status: Active » Needs work

MAINTENANCE_MODE isn't always defined so the patch in #4 causes notices on standard pages.

To clarify this issue:

Problem:
During an upgrade to 7 the user's timezone is still in an offset at the initial pages of update.php. It's not until user_update_7002() that it gets converted.

Solution:
A possible solution would be to only return the user's stored timezone from drupal_get_user_timezone() when not in update.php.

coltrane’s picture

Status: Needs work » Needs review
FileSize
872 bytes

This patch adds a check if MAINTENANCE_MODE is not defined before returning the current users timezone.

This can only be tested on update.php when upgrading from Drupal 6 to 7.

smscotten’s picture

The patch is the right way to go about this, but I just set my user 1's timezone to "0" and figured I'd change it back when I was done. That made the messages go away. Solution offered for other lazy bums like me.

chx’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests
smscotten’s picture

Patch works for me when applied to RC4. (And yes, I set my timezone back to -25200 before I tested.)

smscotten’s picture

...and I had no troubles with this patch on 7.x-dev either.

coltrane’s picture

Hmmn, how to test this.

It's impossible, I think, to test the upgrade process, but we could try and replace $user->timezone with an offset before DRUPAL_BOOTSTRAP_SESSION to cause the error to appear on a standard page.

I'll see where I can get with that.

coltrane’s picture

Actually, the test method in #11 seems really hard to do and it turns out there is an upgrade path test!

And in fact we can trigger the error in the basic upgrade path test if the users created in the base database have a timezone set. So, this patch does this, and it will fail! muaahahahah

coltrane’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 1006838-upgrade-timezone-warning-MAKE-IT-FAIL.patch, failed testing.

coltrane’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
FileSize
1.79 KB

On http://qa.drupal.org/pifr/test/119654 you can see the timezone warning. This patch includes a proposed fix.

chx’s picture

Status: Needs review » Reviewed & tested by the community

That looks nice & the test is somewhat along the lines of what I thought though I did not hope for such a small patch :)

webchick’s picture

Status: Reviewed & tested by the community » Needs work

Welllll, hold up now.

I really do not like comments like this:

+  // Do not use the timezone of the current user if the site is in maintenance
+  // because during upgrade from Drupal 6 to 7 the user's timezone was stored
+  // differently.

in a general-purpose API function in bootstrap.inc.

And the actual fix:

+  if (!defined('MAINTENANCE_MODE') && variable_get('configurable_timezones', 1) && $user->uid && $user->timezone) {

Seems to imply that if I put my site in maintenance mode, the time on all nodes is going to change to whatever the site/server timezone is set, which would be extremely jarring were I to live in, say, Japan, and have a site hosted in the US. We'll get support requests about that for sure, since Drupal seems buggy.

Is there not any way to hack around this from update.php/update.inc?

coltrane’s picture

Status: Needs work » Needs review
FileSize
2.44 KB

Great points webchick, thanks.

Is there not any way to hack around this from update.php/update.inc?

Try this patch, which temporarily disables configurable timezones in update.php so as to use the site-wide timezone for session initialization.

I'm not sure if this would still cause a problem like "the time on all nodes is going to change to whatever the site/server timezone is set, which would be extremely jarring were I to live in, say, Japan, and have a site hosted in the US."

If we're saving nodes during update.php shouldn't it not use the currently logged in user's timezone if they aren't the author of the nodes? In other words, should we be worried about this, is it likely to happen?

bryancasler’s picture

#18's patch worked for me

chx’s picture

do we really need to write back into the DB? won't globals['conf'] instead of variable_set suffice?

Damien Tournoud’s picture

Status: Needs review » Needs work

Agreed with #20. Let's reroll and get this in.

coltrane’s picture

Status: Needs work » Needs review
FileSize
2.05 KB

That makes sense, thanks for pointing it out.

Damien Tournoud’s picture

Status: Needs review » Reviewed & tested by the community

Yay.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.