Does not work unless configurable timezones are enabled

It's worked fine on every site I've tested it on. You're going to have to be more specific with your problem. I'd be interested to know how it could sometimes work and sometimes not.

Note: If you are changed the timezone on your computer back and forth to test it some browsers like Firefox only load the local time zone when they launch, so keep that in mind.

It seems to work briefly after I open the browser for the first time. Then I usually leave the browser tab open (IE 7), and after a while I find that the site has reverted to the default time zone (UTC in my case).

Could it be that the multi-site installation has something to do with it? I use table prefixes for the different sites. You can try for yourself at: http://elephanttrust.net/ and http://blog.michna.com/

There's also http://winhlp.com/, but the default theme there doesn't show the minutes for articles. You could choose a different theme like Garland-fine though. All three sites have a test forum where you can enter a new forum topic or comment to check the creation time.

If it seems to work at first, leave the browser open for a couple of hours, then try again.

My local time zone is GMT (+01:00) Amsterdam, Berlin, etc., with daylight saving time enabled.

Hans-Georg

Complete information is provided through the above Drupal installations. I have reinstalled Auto Time Zone into all three installations to facilitate testing.

All three sites fall back into the default time zone, UTC (= my local time - 2 h, due to daylight saving time).

If there is anything else I can do, please let me know.

Hans-Georg

I set this to "needs more info" because we unfortunately do not know what is causing the problem.

Does anybody else see the problem as well? I'd like to rule out that it's a local defect.

I upgraded to Drupal 5.2 today, but the defect remains.

If anybody wanted to test this, please check one of the abovementioned sites, preferably http://blog.michna.com/, which is the smallest, least critical one.´

All sites have a test forum where you can post test messages after creating an account. I already mentioned my time zone, if that plays a role. I'd be grateful for an independent test.

Hans-Georg

I tried to test the site but I couldn't figure anything out without admin access. Are you seeing log entries showing the time zones being change? For example "Timezone updated from 3.5 to -7". If a users time zone is updated, then changed, it should be automatically updated again.

Thanks a lot for testing!

A simple test is to post a test message (into the test forum), then look at the message's posting date and time. What I see is that the UTC (default time zone) time is displayed, rather than my local time.

In other words, if I post a message at 9:00, its posting time is displayed as 7:00 for my time zone.

Just a sec—there's a new suspicion. Perhaps Auto Time Zone fails when Configurable time zone is disabled? Have to test that. If so, then there would be a simple workaround—enable Configurable time zone, contrary to the recommendation in the Auto Time Zone docs.

I'll leave Configurable time zone off for now to facilitate testing.

Hans-Georg

The Configurable time zone setting has now been changed to on and will stay that way until further notice in http://blog.michna.com/ and the two other sites.

If Auto Time Zone works with this setting, then we have isolated the defect. Auto Time Zone works only when Configurable time zone is enabled, contrary to a recommendation I have read somewhere. To fix the problem I would prefer that Auto Time Zone worked with Configurable time zone off, but a line in the documentation saying that Configurable time zone must be enabled would also formally fix the error, always assuming that this turns out to be the cause.

If anybody tests, please reply here with test results.

Hans-Georg

The purpose of this module was to provide extra convenience for users by automatically setting their time zones when configurable time zones are enabled. However, if you enable the Auto Time Zone setting "Update guest users session variables", it will work as you expect for guest users.

My recommendation would be to (a) re-read #9, and (b) fix the defect.

Background info for people inexperienced in software design: A software defect is that a software module's function doesn't conform with its documentation. The documentation says that Auto Time Zone sets the time zone. In fact, it does in some circumstance, but not in another, which is a defect.

This defect can be fixed either by changing the software module or by changing its documentation. I personally prefer that the software module be changed, but either way is acceptable.

Hans-Georg

The "Configurable time zone" setting shouldn't have any effect on the Auto Time Zone module. In the documentation I recommended that the Configurable Time Zone setting be turned off because the Auto Time Zone module will always sync a users time zone with their browser, so if a user changes the value manually Auto Time Zone will change it back. Thus making that settings option unnecessary, and unusable for the user.

As far as why it's not working for you, I need to duplicate the problem so I can debug it.
Can you confirm that the Auto Time Zone module is not producing any log entries?

The module does write log messages. I just did the following test. The default time zone is set to +0000 (UTC). My local time zone is different (+0200).

1. Disabled the Auto Time Zone module.
2. Set my personal time zone to +0000 (not my normal time zone).
3. Disabled configurable time zones.
4. Enabled the Auto Time Zone module.
5. Observed that the Auto Time Zone module immediately logged that it had changed my time zone from 0 to +2 (correct).
6. Entered a new comment and clicked on Preview.
7. Observed that the comment posting time tag shows the wrong time for time zone 0, rather than +2.
8. Enabled configurable time zones.
9. Entered a new comment again and clicked in Preview.
10. Observed that now the comment posting time tag shows the correct time for my local time zone, +2.

In other words, without enabling configurable time zones all posting time tags of all postings are wrong and relate to the default time zone, rather than to my actual time zone.

Would you like admin rights to one of my Drupal installations for a test? Let's do that by email. My email address (lightly mutilated) is: hans-georg()michna.com

Thanks for bearing with me!

Hans-Georg

Now we're on to something. It looks like Drupals format_date function (http://api.drupal.org/api/function/format_date/5) only uses the individual users time zone value if the configurable_timezones variable is true, otherwise it uses the site default time zone. I'll update the Auto Time Zone module to always set the configurable_timezones variable to true and mention it in the documentation.

Thank you very much for discovering and bringing to light this issue.

Here's a link to the latest Drupal 5 version.

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/autotimezon...

The documentation has been updated but it doesn't tell users what the necessary code is or where to put it.

Thanks for the fix!

christefano: There is no urgency to update. A simple workaround is to manually set configurable time zones to on.

Hans-Georg

No additional code is necessary.

What does this mean? It expressly says that additional code is needed.

This module can set a session variable named $_SESSION['timezone'] for anonymous users, which is in the form of seconds from GMT. This feature is of no use unless extra code has been added to your site to take advantage of it.

I'm not saying that there's a problem with the code. This is a problem with documentation (or, rather, the documentation the module provides in the user interface).

No, it only says that extra code is needed if you want to make use of that feature.

But almost certainly you don't need that feature, so don't enable it and forget about the extra code.

Hans-Georg

I'm not sure that I'm explaining this clearly. Right now the documentation hints at an extra feature but doesn't say how to set it up. If a user wants to make use of this feature, there should be some documentation to help them do it.

Improving the documentation helps users and prevents future support requests.

All the code required to use the bonus feature is given ($_SESSION['timezone']). It's for developers, it's one of those things where if you don't know what it means then you don't need to worry about it. Drupal uses the sites default time zone for anonymous users. The Auto Time Zone module has a feature that can be taken advantage of by another module to use the correct time zone for anonymous users but I'm not aware of anyone who uses the feature.

So maybe it should be stressed in the documentation that the feature is for developers only. It could also be argued that the "Update guest users session variables" configuration option is unnecessary because another module, or block of code that uses the feature could active the feature itself. Now that I think about it that's probably the best way to go. I'd really like to see the Auto Time Zone module integrated into Drupal Core and then all of these issues would be taken care of.

If you are asking about how to use the anonymous user time zone feature that should be in a new issue.

Thanks, LukeLast. I'm just pointing out that there's a lack of clarity in the documentation, not asking how to set it up. Basically, I feel that the text in the user interface needs to be more understandable to users (and this is especially true if Auto Time Zone makes it into core -- which would be great).

From reading this issue, it seems that this module should form_alter() the configurable timezone form element in core so that it is just text that reads "User timezones are automatically set based on the time of their local computer." or somesuch. that way there can be no mistaken setting.

Although Moshe's usability suggestions should be used!

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