Automatically set timezone on user registeration

I think this is fantastic idea and I've been using automatic timezone module for quite sometime.

The only problem I see though is in regards to DST and a user's offset will be affected when this happens. As a result, I think this check should happen more often than just user registration.

However, perhaps that DST patch goes in so maybe this is just superfluous talk...

yup
tested it

I see you removed the install time check function, but then I don't see where you added the call to the generic timezone setting function. Did I miss it or is it actually missing?

*cough*
its there, in the patch

Maybe you could be a little bit more helpful?

Re our attempts to get real timezone handling into core (http://drupal.org/node/11077), is there any way to use javascript to detect the name of the timezone, not just the offset?

Karen, potentially, the JS date object returns the following:

http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_date

On my computer it says "EDT" -- I can't confirm what other computers say, but would that help?

Here are the rest of the date object methods, I don't think anything else is too useful: http://www.javascriptkit.com/jsref/date.shtml

In Firefox on Windows I get 'Fri Jun 29 2007 09:42:23 GMT-0500 (Central Daylight Time), which is possibly useful but doesn't really match anything in the timezone list. With IE 7 on Windows I only get 'Fri Jun 29 09:44:20 2007 ', which is no use at all. Sounds like there are lots of discrepancies.

How about country/city/continent info? The timezone database values look like: America/New York, or US/Central so maybe there's some way to get it that way, or at least to narrow down the possibilities.

Hmm this seems to be the best thread on the subject: http://groups.google.ca/group/comp.lang.javascript/browse_frm/thread/c68...

And the other: http://www.merlyn.demon.co.uk/js-dates.htm#ST

After reading a bit, the best we could hope for is the offset + whether or not the user has daylight savings or not, not much else.

Hmmm, well thanks anyway for checking. Probably not much help.

Hm, I think this could be a nice usability enhancement, so IMHO it is possibly to get into Drupal 6. But I don't understand what is going on around "the killswitch":

+  // Field ID is overridden; so, JS doesn't change timezone on user edit forms
+  // upon killswitch call.

+  // Add the javascript Killswitch to automatically set the timezone.
+  drupal_add_js('
+// Global Killswitch
+if (Drupal.jsEnabled) {
+  $(document).ready(function() {
+    Drupal.setDefaultTimezone();
+  });
+}', 'inline');

"The" killswitch is the if (Drupal.jsEnabled) line. It is called a killswitch because if adequate JS support is not present in the browser, it does not run anything in the brackets. "The" killswitch does not set the timezone as the second comment says, neither it calls anything as said by the first comment excerpt.

I don't think the code comments in this patch are right. Or am I mistaken?

OK, this code was missing a configurable_timezones check, and I also reworded a comment a bit.
Committed the attached patch, thanks.