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
Comment #1
Crell CreditAttribution: Crell commentedForgot to tag. :-)
Comment #2
jensimmons CreditAttribution: jensimmons commented(just for a bit of clarity)
Comment #3
David_Rothstein CreditAttribution: David_Rothstein commentedCool 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.
Comment #4
tstoecklerThen we can also auto-detect 'Default country' which you currently have to enter manually on install.
Comment #5
Jeff Burnz CreditAttribution: Jeff Burnz commentedAn issue here is browser support, lte IE8 have no support for Geolocation API, they would need a polyfill.
Comment #6
jensimmons CreditAttribution: jensimmons commentedIf 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.
Comment #7
mfb@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]
Comment #8
JacineI like this idea. I don't think something like this needs to have a polyfill.
Comment #9
Everett Zufelt CreditAttribution: Everett Zufelt commentedAgreed that this would be nice, and also that no polyfill is required.
Comment #10
Everett Zufelt CreditAttribution: Everett Zufelt commentedIf 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.
Comment #11
Jeff Burnz CreditAttribution: Jeff Burnz commentedIsnt 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.
Comment #12
JacineThis is a really good point to consider. Tagging for UX team.
There's a demo of what happens here: http://html5demos.com/geo.
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. :)
Comment #13
Jeff Burnz CreditAttribution: Jeff Burnz commentedI 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.
Comment #14
mfbSince I often install Drupal for people hundreds or thousands of miles away, I'd actually prefer a map where you select your location.. :)
Comment #15
Crell CreditAttribution: Crell commentedmfb: 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.
Comment #16
klonosIn 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?
Comment #17
Jeff Burnz CreditAttribution: Jeff Burnz commentedAuto 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?
Comment #18
klonosYes, 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).
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.
Comment #19
klonos...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 ;)
Comment #20
larowlanfyi, 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.
Comment #21
larowlanhmm, after some testing realised the webservice requires a registered account (code above uses demo account). damn
Comment #22
giorgio79 CreditAttribution: giorgio79 commentedIE8 is not a concern #1787012: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support)
Comment #23
mitchell CreditAttribution: mitchell commentedAlso, this Timezone Detect module uses a js lib to read the user's timezone.
Comment #24
JordanMagnuson CreditAttribution: JordanMagnuson commentedI'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...
Comment #25
klonosrelated: #1345758: META: Provide locale (regional) formats framework for automated translation of non textual data
Comment #26
klonosPS: I've filed #2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones) for what I proposed back in #16.
Comment #38
markdcWaking 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. =]Comment #39
longwaveInteresting - this can pick up both my timezone and locale:
Maybe we should try using this for default values?
Comment #40
nod_Already the case since #3016427: Default timezone selection incorrect
Comment #41
longwaveIn that case, closing this as won't fix and the linked issue as outdated, given we have a better solution in place already.