The user timezone for vinoth.3v is set to UTC +05.30 (Asia/kolkatta) on production, but it imported differently on git7site.

It appears that existing user time zones are not appearing at all:



Status:Needs review» Active

Thanks for the report!

I'm setting this back to Active for now. Issues should stay as Active until a second person verifies the problem and makes sure there's enough detail for developers to act on the report. (I'd verify now, but the site is being rebuilt).

Unfortunately, the status settings don't quite fit the work we're doing. In a perfect world we'd have a "verified" setting.

I tried to reproduce this by:

  1. Setting my timezone to America/Los Angeles UTC -0700
  2. Creating a new issue
  3. Verifying that the time on the issue matches my current time
  4. Changing my timezone to America/Lima UTC -0500
  5. Verifying that the time on the issue refreshes two hours later than my local time

That worked as expected, but I imagine there are many other places where time comes into play.

Can you share the URL and describe what wasn't working as expected?

Title:User Timezone Incorrect updateUser Timezone Incorrect (D6 to D7)

I think the issue title is misleading.

in d.o(d6), I have my user time zone set to +5.30 (Asia/kolkatta), but in d.o(D7) it was wrong.

Title:User Timezone Incorrect (D6 to D7)User timezone on git7site doesn't match the value on production
Status:Active» Needs review

Thanks for clarifying. I updated the title to make it more clear (I hope).

I definitely see a difference in the way time zones are selected (Region/City - UTC offset on git7site, UTC offset on I'm not sure if this was intentional, but I'll set this to "needs review" so we can find out. D7 upgrade QA» customizations
Issue summary:View changes

edit customizations» D7 upgrade QA

This has to do with the timezones supported by PHP. Named timezones have only been supported since PHP5, and therefore Drupal 6 does not support them. I don't know how the migration is handled exactly, but that is the root of the issue.

Here's an example in the API to show what I mean:!!

Issue D7

The node creation time of a random issue (e.g. this one) also clearly showed it:

Looking at my profile page I noticed that my setting on the D6 site was wrong. It was on utc +1, while brings Europe to UTC +2

After changing the setting on D6

Timezones definitely are not being migrated ...

mysql> select timezone, count(*) from users group by timezone;
| timezone | count(*) |
| NULL     |  1577762 |
| UTC      |        2 |
2 rows in set (17.87 sec)

user_update_7002() handles converting user timezones during the upgrade. Unfortunately, it only attempts to update timezones if the contrib date or event modules have been installed; and if not, it simply sets the timezone to NULL.

So it looks like our options are:
1) Install the date module, so that the timezone_name column exists in the users table (though I'm not sure if the conversions actually get created when the column is added, or simply updated on user_save()), or Update: Looks like the date 6.x-1.x module only populates this column at user login.
2) Leave the user timezones as NULL, and enable the 'Remind users at login if their timezone is not set' setting at admin/config/regional/settings, or
3) Build some sort of custom migration script which attempts to 'guess' the user timezone based on their configured offset. (Example:

Hmmm ... we can't create the timezone_name column from within a drupalorg hook_update_N() function, because this would create a circular dependency (drupalorg_update_7000 depends on user_update_7018(), and we want to sneak in before user_update_7002()).

Based on this, the only way to accomplish #3 will be via a D6 'pre-upgrade' module, which:
i) performs the logic in the linked stackexchange answer to create a mapping of offsets to timezones,
ii) adds a 'timezone_name' column to the users table, and
iii) Iterates across all users, reading their offset value, and writing a best guess timezone into the timezone_name file.

If this is done before the upgrade, then user_update_7002() will then migrate across the timezone_name values, after which the added column can be manually deleted. (Normally it would be deleted by the date_update() functions, which we don't have in this case.)

What is the success rate of the best guess timezone? I'd think it will often be inaccurate, so it may be better to remind the users to set their timezones.

new649 bytes

Given that setting the user timezone to NULL is core's default behavior for D6 to D7 upgrades, and we can't accurately convert each timezone offset to a user's true timezone, we're going to simply enable the "Remind users at login if their time zone is not set" configuration setting.

As a result, when a user logs in and doesn't have a timezone explicitly set, they will be taken directly to their profile edit page and prompted to update their timezone settings. D7 upgrade QA» customizations
Version:» 7.x-3.x-dev
Component:Miscellaneous» Code
Issue tags:+porting

Status:Needs review» Fixed


Issue summary:View changes

Update with examples

Status:Fixed» Closed (fixed)

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