Not sure what happened, but a recent import I did had the timezone set to -18000, which caused problems with adding new nodes. We updated the user.timezone column to be America/NewYork like the rest of the records and it fixed the problem.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | user_import-default-timezone-fix-1979274-5.patch | 985 bytes | incarnated |
Comments
Comment #1
ccarigna commentedI had the same issue and found the problem.
In supported/user.inc, at line 124, the timezone is being set with:
$account_add['timezone'] = '-18000';Using the site's default value would be a better option, such as:
$account_add['timezone'] = variable_get("date_default_timezone", "America/Toronto");Comment #2
FAAREIA commentedIn 1.0beta6, line 20
// $options['user']['timezone'] = t('Timezone');is commented.I tried to make it work in line 124 but i couldn't. I can only make it work with a string.
Help will be appreciated. Marked as active since a string is not a real solution
Comment #3
anybodyThis problem still exists and leads to views-Errors for example later on, because the time offset can not be calculated properly. Settings Priority to major because this breaks Drupal core function results (wrong user timezone provided).
Comment #4
anybodyAdditional information: The correct value for the database is the Timezone identifier as described here: http://php.net/manual/en/timezones.php
As fallback you could set the value to the defined Drupal date settings (default value).
Comment #5
incarnated commentedPatch to set timezone to Drupal default, falls back on PHP default (yanked from drupal_get_user_timezone()).
Comment #6
stefan.r commentedLooks good, this is the same logic as used in
drupal_get_user_timezone().Comment #7
robert castelo commentedThanks for the patch!
Added to User Import 7.x-2.2