Given

2013-03-05_03h30_22.png

Problem

  1. Why is there no - None - for Timezone? If it's possible for Country, why not for Timezone?

  2. No idea what this thing wants from me in the first place!!!

  3. What if my site is international? What's the appropriate timezone for that? WTF?

  4. Shouldn't Timezone default to UTC or something?

  5. Why does it preselect my local timezone? (from my browser) How is my local timezone relevant for the site I'm installing?

  6. ...and why does it preselect Europe/Paris when my actual local timezone is Europe/Berlin? :P

Proposed solutions/Related issues

#1787540: Improve the Timezone Picker
#2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones)
#2083575: Provide better UX when selecting Country/timezone. (depends/postponed on #675446: Use jQuery UI Autocomplete)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Issue summary: View changes

Updated issue summary.

Dries’s picture

Not sure 'Server settings' is the best title for the fieldset either.

sun’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Issue tags: +Sunrise Sanity Cruise
sun’s picture

Issue summary: View changes

Updated issue summary.

Gábor Hojtsy’s picture

"Sunrise Sanity Cruise" lol :D.

These settings have been in the installer forever, so we never really questioned them I guess. I don't really get the significance of the country setting, it is not used for anything in core. I think it would be safe to remove(?).

For timezone, that is a bit different. Assuming your site would receive anonymous traffic, Drupal needs to take a timezone in that case and display dates in that timezone. I cannot just be "no timezone". Unless you mean UTC by no timezone that is. That would likely be more confusing for most people though than just assuming the local timezone of the developer setting up the site. I get that you mean developers could easily set up sites on behalf of others in other timezones, but outside of international providers, it is more likely that you'd set up a site for someone in the same timezone (especially in Europe). So I think this is the easiest to assume.

So my recommendation would be to remove country and leave timezone as-is.

andypost’s picture

+! to remove country that does not used. Commerce sites have own settings for default country in fields

sun’s picture

re: #4: Heh.

From a user perspective, I was able to make more sense of the Country select widget. I was immediately able to relate to that.

But given its default value and my current concrete international use-case, I felt OK with leaving it at "None". However, it would have been faster for me to scan and dissect this form if the description would have been contained in the label already.

I'm still lost on the Default Timezone though.

I'm able to make sense of my own user timezone. But of what matter is the default timezone? :)

And if it's used to display dates to unknown users, I still don't get why there cannot be a default of "None" (UTC?) :) I'd assume that would display all dates in the respective original date/time in which the respective users/authors entered them? :)


Technoschizophrenics:
Unless I'm mistaken, the default timezone also has a range of additional consequences with regard to how date input values of users are processed, stored, and output... no?

Gábor Hojtsy’s picture

@sun: your site would be hardly indexable with googlebot / cacheable in whatever cache if all visitors would have the times display in their own timezone. If it would default to UTC for anonymous users, I'm sure we'd get fired with regular bug reports about mistaken dates/times on posts. When people post something and check from their tablet and see it displays a totally different time, its a bug. The default timezone is also used to configure new users. After all a timezone setting on the user registration form would be a much bigger WTF, than seeing it in the installer.

Bojhan’s picture

I am not really convinced this belongs in the installer either, loads of webapps/CMS's get around not having this in the installer.

sun’s picture

I likely need to file a separate issue for this, but:

system.timezone.yml:
---
default: Europe/Brussels
user:
  configurable: '1'
  default: '0'
  warn: '0'

Hey, there's apparently a site-wide default timezone — and another default timezone for users! :)

Shouldn't the user default timezone default to the size-wide timezone? If not, why is it configurable? :)

Gábor Hojtsy’s picture

I think what is that timezone going to be used for applies. On a default standard install, these are the default settings for user timezone:

Screenshot_3_5_13_12_46_PM.png

That is, users could set their own timezone, NOT on the registration form, so those who do not go and proactively edit their own timezone will get the site timezone. That makes the initially set / picked timezone pretty significant for the site. All users inherit time timezone.

Dragan Eror’s picture

What about taking server time as default time, instead from browser?

JohnAlbin’s picture

What about taking server time as default time, instead from browser?

That's what Drupal used to do. But it was considered poor UX because the location of the server does not correlate with the location of the website audience. The location of the user installing it seemed to correlate closer to the website audience location.

I'm in favor of removing the Default country list entirely given that a.) we don't use it in core and b.) #1938892: Switch from ISO-3166-1 country data to CLDR unicode data

Pancho’s picture

No, we certainly shouldn't remove the country list from core!
We're on a good way to making Drupal core an awesome base for multilingual, international websites.
However, compare with your favorite operating system. Even with the huge D8MI agenda getting finished, there will be a few pieces missing, including:

  1. decimal delimiter / thousands separator (by country)
  2. numeral systems (by country)
  3. timezone suggestions (by country)
  4. calendar system (by country)
  5. date and time formats (by country)
  6. first day of week (by country)
  7. And possibly:

  8. first / last working day (by country)
  9. secondary language suggestions (per country)
  10. telephone number validation and formatting (by country)
  11. metric / imperial measures (by country)
  12. currency (by country)
  13. ...

All of these features, UI-improvements and then possible bug fixes go by country, not by language.
With CLDR, we just switched to a database that gives us great data for all of these future improvements.

Some of them are already doable in D8:
See the 'Default country' select box. It could default to the most probable country for the given primary language and list the other probable options first. For many languages this default country would make sense, and it would decouple it from the admin's browser locale. The data we need is in CLDR.
Or the 'Default timezone' select box sun was complaining about. It could simply default to the most probable timezone for the chosen 'Default country'. For most countries this default would perfectly make sense. All data is in CLDR.
Or see the date and time formats and the 'First day of the week'. This always bugs me that I have to manually set them up, even though the system knows the default country.

What I agree with is that we actually should make use of the 'Default country' in core.
So let's keep this issue a UI improvement request and let's leverage the CLDR dataset for more than just the 'Default country' and the 'Default country' for more than decoration.

Could the country list be in contrib?
Sure it could. However, then there won't be the UI improvements in the installer. And probably the basic setup of "Regional settings" and "Date and Time" formats should be handled by core, too. And for decimal delimiter / thousands separator we'd need to create an API.
And then we'd need an contrib API module to avoid isolated one-off modules. Would changes in country data be taken care of correctly enough, so contrib can build on it?
No, IMHO the country list really belongs in core. It has always been (at least for a long time). And if we threw it out now, and a good contrib API successor would emerge, then it would be the next candidate for re-inclusion in D9. I think we don't want this kind of hopping between core and contrib. Let's keep and improve, maybe extend a bit the basis that we have, so contrib and custom code can continue building on it.

Pancho’s picture

Issue tags: +country list

Oh, that's probably been too many unnecessary words and paragraphs...

DrupalDateTime uses the Default country, so it can provide DateTimePlus with the country code needed to leverage PHP's IntlDateFormatter class.
See also #1345758: META: Provide locale (regional) formats framework for automated translation of non textual data .

Hanno’s picture

If the country select list stays, we could as a UX improvement use the country to filter (or for smaller countries - select) the right time zone(s), assuming we have a mapping of countries -> timezones

Gábor Hojtsy’s picture

Sounds to me like the timzone still makes more sense to detect from the browser. We also do that for language on the first installer step.

Hanno’s picture

Ok, one way or another, for UX it might make sense to link timezone and country. If I choose Europe/Amsterdam as 'timezone', I might assume that the default country would be 'the Netherlands', and if I choose 'Europe/Brussels', the default country will be 'Belgium'. People now have to choose in two select boxes a location, and it doesn't seem related. The wrong combination can cause unexpected offsets as the daylight savings are country specific (http://en.wikipedia.org/wiki/Daylight_saving_time_by_country).

klonos’s picture

@Hanno, #15:

...assuming we have a mapping of countries -> timezones

For starters, thanx for pointing me here from #2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones) where I explain that there already exists such a list/mapping:

http://en.wikipedia.org/wiki/List_of_time_zones_by_country

@Gábor Hojtsy, #16:

It does make sense to detect timezone from the browser/OS when we deal with the site visitors (especially anonymous). We could also do that as a fallback if a registered user has opted out of specifying a country (for privacy reasons) or even perhaps detect based on visiting IP. But for the installer, IMO it makes more sense to evaluate the fact that we can use the php.ini date.timezone parameter. I understand the reasoning behind the logic of "server might be located elsewhere", but it could as well be a VPS server where the admin actually has access to these settings and indeed sets the preferred timezone (that is precisely my use case btw).

So basically ideally we could have something like this:

1. Detect timezone and country on the server side for the installer.
2. Detect the timezone and/or country from the admin (site builder) browser/OS/IP.
3. Offer both options detected from steps 1 & 2 in the form of a radio set. Preselect either one of these options (we can bikeshed over which one).
4. Offer a third "other..." option that presents the whole list of countries/timezones but keep the drop-down hidden unless this radio is actually selected. This will keep the UI to a minimum (no long drop-down menus) unless we did not do a good job "guessing" what the user intended. The admin (site builder) can still specify a different set as they see fit.

They can do so by either selecting country or timezone since if they have a one-to-one mapping, then they are interchangeable. If their preferred country spans over multiple timezones, we limit the respective drop-down to only those applicable (that's where #2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones) comes into play).

5. Whatever the choice from step 4 above sets the site default country/timezone pair.
6. Anonymous users see things adjusted to the site default country/timezone from step 5 (behavior can also be augmented by contrib with IP detection).
7. Now, for registered users:

- We check to see if site policy allows them to set their preferred country/timezone (if not, we do nothing special and simply use the site default from step 5).
- If site policy allows them to override the country/timezone setting, we then make another check to see if they are allowed to have empty values (for privacy reasons). If they are allowed and they have not specified a preferred set in their profile form (or if the site is configured to use the default set for new users), we again simply fall back to the site default.
- If they are allowed to override the site's default country/timezone with their preference, we use a similar logic as with the installer:

a) detect things from browser/OS (or IP with contrib) and offer it as an option.
b) offer the site's default as an option
c) offer a "other..." option (and hide the huge drop-downs form the UI) - again employ #2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones) for better UX.

This time we preselect none of the above options in order to honor the empty country/timezone possibility.

How does that seem to you?

PS: we should definitely not kill the country - we'll need it if we are to implement #1345758: META: Provide locale (regional) formats framework for automated translation of non textual data

Hanno’s picture

@klonos the wikipedia page isn't the mapping we can use.
But this works:

a. If the country is selected, this gives an array of all the timezones in that country:

$timezones = DateTimeZone::listIdentifiers(DateTimeZone::PER_COUNTRY, $countrycode);

b. If the timezone is selected, you'll get the country code of that timezone with:

$tz = new DateTimeZone("Europe/Amsterdam");
$countrycode = $tz->getLocation()['country_code'];
Hanno’s picture

Note that there is also the initiative for a visual timezone picker: #1787540: Improve the Timezone Picker
Awesome if we can integrate that one.

klonos’s picture

If we used an autocomplete (or better an autocomplete + drop-down combo) instead of the simple drop-down we have in place now, that would be a small (but rather quickly implementable) step towards better UX.

afeijo’s picture

Great idea klonos! I will work it since I will add the timezone picker

klonos’s picture

Title: Locale settings in Drupal installer make little (UX) sense » [META] Locale settings in Drupal installer make little (UX) sense

Well, it does deserve its own issue I guess. So, let's make this a meta where the possible solutions are discussed but split off in various separate issues. Work can be done in parallel in these separate issues (and thus progress faster) and even if one proposed method fails to move, then perhaps we go with the simplest one and keep the other(s) in mind as improvements/additions for later on. At this point let me take the chance to say that I really like the idea of #1787540: Improve the Timezone Picker, but I expect it to take way longer than simply using jQuery UI (it does feel that #675446: Use jQuery UI Autocomplete is getting really close).

Edit: here's the separate issue: #2083575: Provide better UX when selecting Country/timezone.

klonos’s picture

Issue summary: View changes

Updated issue summary.

klonos’s picture

I didn't go through the whole issue in order to provide a proper issue summary, but I've added the previously mentioned issues plus #2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones) to it as a "Proposed solutions/Related issues" section.

klonos’s picture

Title: [META] Locale settings in Drupal installer make little (UX) sense » [META] Locale settings in Drupal make little (UX) sense

...this does not refer to the installer alone plus it is already assigned to the language system component. Besides, we do have the "installer" tag in place.

klonos’s picture

Issue summary: View changes

...adding some proposed solutions/related issues

Berdir’s picture

Issue summary: View changes

Small note: The country *is* used, for some reason that I don't full understand yet, we only use the native php intl date formatter if we have a configured country. That tests don't is the only reason they're not exploding everywhere we edit nodes because that is right now broken if you are using intl and don't have the datetime module enabled: https://drupal.org/node/2031183

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
catch’s picture

Category: Bug report » Plan

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.

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

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

sleitner’s picture

Version: 9.5.x-dev » 11.x-dev

The country is also needed for the date format, because the e.g the month names may differ between countries with the same language:

January in German German is Januar, but in Austrian German it is Jänner