Wrong time zone defaults for some countries

This is very odd; 'db_register "tzsetup/country/$CC" time/zone' ought to take care of setting a sane default, I think.

This also isn't reproducible in ubiquity despite the code being essentially the same, which I think suggests some deeper problem. I wonder if time/zone is preseeded when oem-config starts?

There's enough information here, but I want to investigate a bit more.

The suggestion of coming up with a better way to select the time zone
is a good one, and the case of "Español" is a good example of the
complications involved. I agree we need a better way. However, the fix
suggested would be a worse solution than the current default.

New York is a BETTER selection than any European time zone. In the
United States alone, 34 million speak Spanish at home, which is
roughly comparable to the number of native Spanish speakers in Spain
itself. Most Spanish speakers are in Latin America; of all countries
with majority Spanish speakers, only Spain is outside of the Americas.
Mexico has the most native Spanish speakers of any country, including
Spain. If you want to make a reasonable default, Central Time (aka
Chicago) has the most Spanish speaking people. A Least Squares
regression to take into account the Spanish speaking population around
the world, New York turns out to be the right choice. (While it's not
the zone with the greatest number, it is "least wrong" on the whole. )

Most of IYCC's customers are native Spanish speakers, born and raised
in Texas, in the Central time zone. Few of them know to select
"Chicago" as their time zone. How are folks in south Texas supposed to
know to pick Chicago as the correct time zone, when Texas is the
second most populous state in the United States. (Texas has twice the
number of inhabitants as the entire state of Illinois, where Chicago
is located.)

To complicate matters more, several parts of the Central timezone have
their own rules. The state of Indiana has a few locations that have in
the past opted out of Daylight Savings Time, so there are separate
rules for them. The hapless Spanish speaking Texans have no way of
knowing which of the little dots on the map they are supposed to
click, and it's difficult to select the one you want when you do.

Perhaps a better solution would be to simply ask the user to type the
country, state or province, and city (or perhaps postal code) and have
the system prompt with a reasonable choice. There are many widely
databases that have location information, and there's just no reason
to require the user to figure it out. Besides, the location
information could and should be used for populating, inter alia, the
"About Me" address fields and the OpenOffice.org User Data infomation.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

Loye, this is completely off-topic. If you want to raise this, please file a separate bug. The bug that Michael raised applies to many languages other than Spanish.

Incidentally, an OEM is completely free to, and indeed is somewhat expected to, customise things based on their own expected customer base.

This affects many more languages than just Spanish.

Here's a list of countries that are affected by this (as of 1.37.2): AQ AU BR CA CD CL EC ES FM GL ID KI KZ MN MX NZ PF PT RU UM US. All of those default to New York time.

For example, if your language is Russian (RU), your country defaults to RU. This country has a tzsetup/country/RU setting, and so would default to New York. That's probably not the best default.

Loye, it sounds like you're suggesting that Spain not be the default country for Spanish. That's a subtly different bug than this one -- that once we think the user is in Spain, we set the default time zone to New York.

I can reproduce this, and time/zone is *not* preseeded. How odd. Unfortunately I forgot to run in debug mode so there'll be a slight delay while I reinstall and do that ...

> Loye, it sounds like you're suggesting that Spain not be the default
> country for Spanish. That's a subtly different bug than this one --
> that once we think the user is in Spain, we set the default time zone to
> New York.

Perhaps I didn't clearly make the connection between the report and my comments.

From the bug report:

>If you enter Catala or Espanol as your language (for example), your
>country is marked as "ES" (so far so good). However, when you get to
>the timezone page, your default timezone is New York!

1. The reporter suggests that language is a good basis for inferring
country and concomitantly tzsetup/country/CC. I disagree. In the
particular case of Español, for example, the default country
_should_not_be_ Spain, but rather Mexico, and the timezone should be
either Central or Eastern (depending on your preference for modal or
least squares default selection).

2. I agree, however, that the selection of timezones needs a
revamping because the way we do it now will get the answer wrong more
often than right. My suggestion is to change the way we select
timezones altogether.

Happy Trails,

Loye Young

Loye, I'm afraid I must insist that bug reports be kept to a single topic, otherwise it is impossible to manage them. I've said this once already - *please file a separate report* so that we can deal with the release-critical issue in *this* one.

The release-critical issue in question is that oem-config diverges from the handling of countries in other installer applications (d-i and ubiquity). I am absolutely not going to deal with this on an application-specific basis, and we aren't going to change the general handling of countries for 8.10.

This turned out to be a little different from the originally-proposed patch. The problem was that oem-config was picking up a default from /etc/timezone or /etc/localtime, which generally ended up overriding the default that would usually have been set automatically by debconf. There was also a secondary problem that the language component was keeping the originally-set country when the language was changed, rather than expecting there to be a new default set by localechooser.

Here are the patches I ended up committing:

  http://bazaar.launchpad.net/~ubuntu-core-dev/oem-config/trunk/revision/543
  http://bazaar.launchpad.net/~ubuntu-core-dev/oem-config/trunk/revision/544

This bug was fixed in the package oem-config - 1.52

---------------
oem-config (1.52) intrepid; urgency=low

  [ Colin Watson ]
  * Reset debian-installer/country if the language is changed, as otherwise
    we can end up defaulting to an inappropriate country for the language.
  * Stop defaulting to the timezone from /etc/timezone or /etc/localtime, as
    this has a nasty habit of overriding the usual defaults for countries
    with multiple timezone choices (LP: #283861).
  * Update translations from Launchpad.
  * Automatic update of included source packages: user-setup 1.20ubuntu10.

  [ Evan Dandrea ]
  * Pull timezone map changes from ubiquity:
    - Iterate through a list of nearby timezones on click, rather than
      selecting the absolute closest timezone to the pointer.
    - Stop scrolling the timezone map once the mouse is outside its
      boundaries (LP: #251231).

 -- Colin Watson <email address hidden> Thu, 16 Oct 2008 19:45:48 +0100