User timezone on git7site doesn't match the value on production

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?

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 drupal.org). I'm not sure if this was intentional, but I'll set this to "needs review" so we can find out.

edit

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:

https://api.drupal.org/api/drupal/includes!common.inc/function/format_date/6

https://api.drupal.org/api/drupal/includes!common.inc/function/format_date/7

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

• https://drupal.org/node/2090757 " September 17, 2013 at 8:24am"
• https://git7site.devdrupal.org/node/2090757 "September 17, 2013 at 7:24am"

Looking at my profile page I noticed that my setting on the D6 site was wrong. It was on utc +1, while http://en.wikipedia.org/wiki/Daylight_saving_time brings Europe to UTC +2

After changing the setting on D6

• https://drupal.org/node/2090757 " September 17, 2013 at 9:24am"
• https://git7site.devdrupal.org/node/2090757 "September 17, 2013 at 7:24am"

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: http://drupal.stackexchange.com/questions/37006/convert-d6-user-timezone...)

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.

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.

Committed.

Update with examples