I'm not sure how practical this is, but I figured I'd throw it out.

Currently, the installer tries to detect a user's timezone using, I believe, Javascript to "guess" what the user's timezone is. This works decently, but in my experience not always. For example, in Chicago during daylight savings it always thinks I'm in Cuba. :-)

However, HTML5 offers fun new functionality to detect a user's physical location, within reason. Timezones, as we all (should) know by now, are based on location, not just offset. So if we can detect the closest timezone region to a user during the installer that should give us more accurate data, as well as being just a cool use of the technology.

Discuss.

Comments

Crell’s picture

Issue tags: +html5

Forgot to tag. :-)

jensimmons’s picture

Title: Use HTML5 location support for timezone detection » Use Geolocation API for timezone detection

(just for a bit of clarity)

David_Rothstein’s picture

Component: install system » system.module

Cool idea, but the timezone stuff is an API provided by system.module. (The installer is just one small place that uses it. For example, it runs on user profile pages also.) So, moving this to system.module.

tstoeckler’s picture

Then we can also auto-detect 'Default country' which you currently have to enter manually on install.

Jeff Burnz’s picture

An issue here is browser support, lte IE8 have no support for Geolocation API, they would need a polyfill.

jensimmons’s picture

If this is a new feature, we don't necessarily need a polyfill. IMO, polyfills are only required when we replace existing functionality. Otherwise lets keep things simple. We discussed this at the Core Conversation about HTML5 and Drupal 8. The slides for that are at http://jen.cm/h6. We plan to open up a place for everyone to discuss the Guiding Principles I presented once we have a final decision about where to do so.

mfb’s picture

@Crell re: defaulting to America/Havana rather than America/Chicago, not sure what your environment is but I found what might be a Firefox bug in the Date.getTimezoneOffset() method.. On Ubuntu 10.10 Firefox 3.6 it's always returning the same value when it should vary depending on whether or not DST is in effect, but it works correctly on Ubuntu 10.10 Chromium and Ubuntu 11.04 Firefox 4.. [Edited to clarify versions]

Jacine’s picture

Issue tags: +D8H5

I like this idea. I don't think something like this needs to have a polyfill.

Everett Zufelt’s picture

Agreed that this would be nice, and also that no polyfill is required.

Everett Zufelt’s picture

If we decide to do this we will need to decide where to get the Country / Timezone data. I.e. geoLocation allows us to probe for location, but does not allow us to magically get the country and timezone, we would need to use a lookup for this information.

There is also the question of whether it would bother a user to have the 'This page would like to access your location' message on UIs where this is included. I am not sure how intrusive / scary browsers are when requesting this information.

Jeff Burnz’s picture

Isnt the proposal to replace existing functionality? So in this case those older browsers would have no functionality without polyfill, right, so in effect we would be deprecating lte IE8 from having any sort of automagic time zone setting. I'm not fore or against this, just trying to understand why no polyfill is needed.

Jacine’s picture

Issue tags: +d8ux

There is also the question of whether it would bother a user to have the 'This page would like to access your location' message on UIs where this is included. I am not sure how intrusive / scary browsers are when requesting this information.

This is a really good point to consider. Tagging for UX team.

There's a demo of what happens here: http://html5demos.com/geo.

Isnt the proposal to replace existing functionality? So in this case those older browsers would have no functionality without polyfill, right, so in effect we would be deprecating lte IE8 from having any sort of automagic time zone setting.

IMO, that is the proposal and is perfectly okay. If you want to use IE8, great, but you can take 5 seconds to fill it out yourself, instead of Drupal carrying around bloat for it. That's just my take on it, though, so feel free to disagree. :)

Jeff Burnz’s picture

I wonder if there is some legality involved in that message being shown, here in EU there are very strict rules regarding gathering and usage of information.

mfb’s picture

Since I often install Drupal for people hundreds or thousands of miles away, I'd actually prefer a map where you select your location.. :)

Crell’s picture

mfb: Just selecting the default timezone based on geolocation API is fine. I would not recommend removing the select box, just using a more modern approach to select the default.

klonos’s picture

In D7, if one goes through the installer and selects a country, they also have to set the timezone. This might be a desired feature for some countries that span over various timezones (though it would be great to limit the list of values in the drop-down to only the timezones that apply to that country), but it would be great if it was so that if a country is within a single timezone, the respective timezone is auto-selected.

For example, I always select Greece for the country, but the timezone is set to "Europe/Helsinki" instead of "Europe/Athens" (??). So, I always have to take an extra step to select the proper timezone too. I always mumble that Drupal should be smart enough to understand that if I set the site's country to Greece, then the timezone is most likely Europe/Athens. This doesn't happen despite the fact that I've set this in my php.ini date.timezone parameter. So, I'd also like to take the opportunity to suggest that we also read this parameter and preselect the value from the drop-downs. This would provide "sensible defaults" for most installations and require less clicks during setup.

Finally, I'd like to say that this "bug" becomes more obvious when a mistake was made in one or the required fields. If you don't enter a proper email address for example, these fields (country and timezone) get reset when you are redirected back to the same page. The user either notices it and re-selects the desired values from the drop-downs or fails to notice it and ands up wondering why the site's users and up with the "wrong" default timezone.

PS: Using the geolocation might be ok for when new users register in a website from various locations over the world (less clicks for them - better UX during registration) and I realize that this issue got switched from the install system component to the system.module to cover this case back in #3, but what if the site is being built with a certain country in mind? The admin setting it up might not be located in that country. In such cases, I believe that we'd better be auto-selecting the country/timezone pair for the site installation section by taking under account the country and timezone reported by the server/OS and let geolocation do its magic only in the user profile section when users edit/create their profile. What do you think?

Jeff Burnz’s picture

Auto selection means maintenance of such a list and potentially being out of date and requiring updates - perhaps this is a pita we can avoid. I know Russia changed its time zones this year, moving things around a bit and ditching daylight saving. On that point the list would need to account for these countries with multiple time zones.

Wouldn't the "what if the site is being built with a certain country in mind" scenario be an edge case, compared to the vast majority?

klonos’s picture

Auto selection means maintenance of such a list and potentially being out of date and requiring updates - perhaps this is a pita we can avoid. ...

Yes, these things might change, but how often will that happen? IMO it's worth the pita if it is in order to provide better UX (defaults that make sense out of the box).

Wouldn't the "what if the site is being built with a certain country in mind" scenario be an edge case, compared to the vast majority?

I personally think not. I always build sites for Greek owners, intended for Greek audience (registered users), but translated to English or perhaps a few other languages too (for visitors from other countries - they usually browse but never register). Greece has only one timezone and it is a sensible default in such cases. I'm sure the same applies to other small countries with a single timezone. Not an edge case at all if you ask me.

klonos’s picture

...just to support my claim that this in far from an edge case: this list shows that there's only 21 countries with multiple timezones and the rest of the 175 countries have a single timezone. Someone would naturally argue that among the 21 countries with multiple timezones are the largest (and perhaps most internet-active) ones, but still countries like India and China have a single timezone. My point I guess is that instead of arguing over if this is an edge case or not, we should be thinking if this would significantly increase UX.

As for the PITA, I volunteer to monitor this list of countries and maintain it by providing patches if any changes happen to occur in the future (I'll just need someone to point me to the file and part of code holding this list).

Anyways, what I propose seems to me as something that will solve (either partially or completely) the WTFs I mentioned in #16. If this heads a different way, I'll simply file separate issues for these "bugs" anyways ;)

larowlan’s picture

fyi, just playing around with the webservices here http://www.geonames.org/export/ws-overview.html I was able to use html5 geolocation and two $.getJSON calls to get spot-on values.

See http://jsfiddle.net/7uyqs/31/ for how simple it was.

larowlan’s picture

hmm, after some testing realised the webservice requires a registered account (code above uses demo account). damn

giorgio79’s picture

mitchell’s picture

Also, this Timezone Detect module uses a js lib to read the user's timezone.

JordanMagnuson’s picture

I've been looking into automatic timezone detection for some time... One of the significant disadvantages of using html5 geolocation as opposed to a javascript solution, in my opinion, is the fact that most browsers will not process that information without the user's express permission (see screenshot from Chrome). To a lot of users that kind of "allow access to your physical location" popup is scary, and not something they are going to okay. It is also not a "silent" solution, and disrupts whatever the user happened to be doing...

Personally, I've been quite happy with results from the jsTimezoneDetect library that I'm using in the Timezone Detect module. It accounts for daylight savings time, and almost always chooses a timezone that can be used equivalently to your actual timezone (if not actually the same Olson ID). It also produces more accurate results than geolocation methods when a region changes timezone, and for users on border areas in low population regions, since it is drawing directly from the client's actual set time, rather than a manually maintained database. This is the case with my current residence, Amman, Jordan, where daylight savings time was abandoned a few months ago, but none of the major geolocation databases have been updated yet...

Anyway, just a couple of thoughts...

klonos’s picture

klonos’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

markdc’s picture

Issue summary: View changes

Waking this up from the dead.

FWIW, here's a clever use of Intl.DateTimeFormat() to pinpoint a person's country. It was fairly reliable in my tests. Not sure if it can be utilised for this feature. Maybe it's worth a look. =]

longwave’s picture

Interesting - this can pick up both my timezone and locale:

>> Intl.DateTimeFormat().resolvedOptions().timeZone
"Europe/London"
>> Intl.DateTimeFormat().resolvedOptions().locale
"en-GB"

Maybe we should try using this for default values?

nod_’s picture

longwave’s picture

Status: Active » Closed (won't fix)

In that case, closing this as won't fix and the linked issue as outdated, given we have a better solution in place already.