Features/TimeZoneAndLocation

Time Zone / Location / Locale Improvements

Summary

Improve the handling of time zones, and related to that, the handling of location in general, and related to that, locale in general. (The exact scope of this feature is not yet completely determined.)

Owner

• Name: DanWinship

Current status

• Targeted release: Fedora 10
• Last updated: 2008-08-05
• Percentage of completion: 50%

libgweather includes a location-selection entry, and intlclock uses it. Timezone names are localized in the location database.

Detailed Description

Redundant Time Zone / Location Setup

We currently have (at least) 3 timezone settings in Fedora:

• The system timezone, set in firstboot or from system-config-date. (They both use the same code.)
• The (default) intlclock timezone/location (which is also used to get weather information).
• The user can also choose additional locations to show the time/weather of
• The evolution calendar timezone

Although the system timezone is nominally system-wide and the intlclock and evolution timezones are nominally per-user, most users will want all three to be the same. evolution should pick up the system timezone automatically by default, although for historical reasons it does not. intlclock on the other hand cannot set up a "location" entry based solely on the system timezone, because it needs information about weather stations as well, which can't be derived from the timezone. So if we want intlclock to be correctly configured automatically, that means the user has to pick a location rather than merely a timezone during firstboot.

Location-picking UI

• To set your location in intlclock, you type in a city name, or pick it from a long list (which at least supports find-as-you-type). If your city isn't in the list, then you have to guess a likely nearby city, or else find your country or region in the list and then scan through the available cities.
• For comparison: OS X's weather dashboard widget is configured with a text entry that accepts a "City, State or ZIP Code". You can enter any city in the world (it pops up a list of completions/disambiguations if necessary); if there is no weather station there it will use weather data from a nearby station. (This seems to be how most online weather sites work as well, qv libgweather bug 530178 .)
• The initial weather location is set based on the address you entered into the product registration form during their firstboot equivalent.

Unless we can embed Google Maps into the UI, which we presumably can't, we need to stick with a textual interface here. intlclock's current interface can be improved upon. We may be able to use a free webservice like GeoNames to map arbitrary city names into coordinates which can be used to find a nearby weather station.

libgweather bug 538464 covers "improved location-selection UI". It has a patch implementing a location entry that autocompletes from the libgweather Locations db.

Time Zone UI

Even if timezone selection is primarily a side-effect of the location-selection UI, we still need to present our guessed timezone to the user, and allow them to correct it if it's wrong. (And there are also other situations where we need to present timezone names, such as in the evolution calendar.)

• firstboot/system-config-date and evolution use a zoomable map, with the tzdata examplar cities marked on it, and a list or combobox containing all of the timezones underneath. The user can either pick a timezone from the (very long, poorly-organized) list, or else pick it on the map. In some cases, the place you need to click on the map does not really correlate well with your actual location. (Eg, if you live in Miami, you must click New York City, 1088 miles (1751 km) away.). The timezone names are mostly unlocalized.
• intclock provides a combo box showing your current timezone or allowing you to select one of the 400 others. The timezone names are not localized.
• In OS X, to change the timezone, you're given a map of the world, but without any cities marked. When you click on the map, it highlights a vertical-ish band indicating a particular GMT offset, marks a city close to where you clicked, and asks you to pick the closest city from a pop-up menu. The list of cities is larger than the set of cities that have associated tzdata timezones, but not unmanageably large. (Eg, the GMT-5 strip contains 12 US cities, 3 Canadian cities, and 6 Central/South American cities.) When you click on a city, it identifies the timezone with a timezone abbreviation. (Eg, "EDT".)
• On Windows, the timezone selector is a pop-up menu containing 90-or-so timezone names, ordered by GMT offset. All of the names are of the form "Foo (Standard|Daylight|Summer) Time", and many of them were apparently made up by Microsoft. (List here with mappings to tzdata names.)

There are two issues here:

• It should be easy to pick a zone
• It should be easy to recognize what a zone refers to

For the former, a 400-entry combo box is clearly not good, and the evolution/system-config-date map interface is also confusing in some ways. If we want a map-based interface, something like OS X's would be better (although we don't currently have any information about the shapes of timezones). OTOH, since the timezone picker is primarily needed when the location picker fails, it may be better to have a non-map-based interface, so that it's not biased in favor of making the same mistakes the location interface makes.

tzdata explicitly identifies which countries go with which timezones, so we could filter the list to only show timezones that are relevant to the current country; this would cut the list down from 400 entries to at most 11 (for Russia). We could also add the "generic" timezones (eg, "GMT-5") at the end of the list, to be used as a last resort in cases where tzdata hasn't kept up with the latest changes.

As for recognizing timezone names, there are three issues:

• Timezone names are currently being used unlocalized in most contexts; Chinese users are forced to recognize "Asia/Shanghai", rather than "亚洲/上海".
• Many countries have official timezone names like "Eastern Standard Time" and "Central Daylight Time" that are much more familiar to people than the tzdata names are. tzdata offers abbreviated local names ("EST", "CDT", etc) for timezones, but they are not all unique.
• tzdata defines a timezone as being any region that has a unique history of GMT offsets and DST rules since 1970. This clashes with the ordinary sense of the term, which only considers the current offset/rules to be relevant.
  • Some of the timezones in tzdata have been obsolete (ie, competely subsumed into a larger timezone) for years, meaning that if we present both of them, we force the user to make a completely irrelevant decision between the two.
  • In other cases, although the distinctions are still relevant, they don't match the distinctions that ordinary people make. Eg, when a city in Indiana in the US switches from GMT-5 to GMT-6, tzdata represents this by creating a new timezone for that city, but in real life everyone describes it by saying that the city switched from being in the "Eastern Time" zone to being in the "Central Time" zone.

Some of these issues are discussion in libgweather bug 529054 .

Automatic Location Detection

In some cases, it might be possible to automatically detect the user's location: if the user has a GPS device attached to the computer, then obviously that can be used. There are also web services that can guess a computer's location with some degree of accuracy based on its IP address (and NetworkManager lets us know when the IP address changes).

GeoClue is a project designed to interface to various local and online location services, and it provides a D-Bus interface for determining the current location. It has been packaged for Fedora (review bug 442693 ).

When it is possible to detect a location change, we could automatically add a new location to intlclock, which the user could then select if they wanted to update their timezone.

Location-based Configuration

What else can be configured on the basis of location?

• Default language/keyboard layout/locale assumptions.
  • By the time firstboot runs, the user will have already chosen a language and keyboard layout. However, some users will have chosen en_US for the system language even though they are not in the US; generally they want LC_MESSAGES to be en_US.utf8, but LANG to be the correct default for their location (so as to get the right paper size, etc). We could do this automatically / semi-automatically.
  • Apparently anaconda only lets you pick "English", not specifically en_US, en_GB, etc. (And presumably likewise for other languages.) So we should attempt to nationali[zs] e the base language setting appropriately at this point. (Being aware that some non-US people may nonetheless prefer to stick with en_US.)
  • See also this thread on fedora-devel-list, bug 442567 , bug 432887
  • There is also the question of web browser Accept-Language ordering when LC_MESSAGES does not match the location. There is not a single right answer here.
• We can't have the user pick a location in anaconda and then guess the language/keyboard from that, because a map-based interface for picking location is complicated enough that it requires instructions (at least "pick the city closest to your location. click to zoom / right click to zoom out"), which requires knowing what language to show the instructions in; and a typing-based interface for picking location requires knowing what kind of keyboard the user has beforehand so you can interpret the typing.

More blue-sky-ish, and possibly dumb:

• We could compare the user's home location against a list of known Linux User Groups, and if there's one nearby, we could have a link to it from the start page in Firefox.
• Likewise, if the user later changed the location away from the original value, we could assume that they are travelling, and try to provide helpful links to tourist information, local news, currency conversion, etc.

Benefit to Fedora

Integrating the disparate dialogs and replacing Fedora-local code (eg, system-config-date) with upstream functionality (GeoClue, libgweather/intlclock, etc) etc will simplify maintenance.

Scope

• libgweather / intlclock
  • time zone localization issues (libgweather bug 529054 )
  • UI improvements to location selection:
    • do completion/find-as-you-type directly from the "Location Name" entry rather than requiring a click on "Find..."
    • allow alternate forms of entry. Eg, "city, state" or "city, country" to disambiguate same-named cities.
    • recognize abbreviations for state and country names, recognize postal codes, etc
    • look up names in a free online database when possible
  • UI improvements to timezone selection:
    • When using pop-up menu, limit it to only show likely timezones, and put the others in a separate dialog. Or else, show the likely ones first, then a divider, then the unlikely ones
    • Do we want to keep the map? Can we make it better?
    • Instead of picking the timezone of the closest tzdata exemplar city to the click, we could take the timezone of the closest Locations.xml city (though still only showing the tzdata cities, or at least, not all of the Locations.xml cities).
  • Automatic location/time tracking
    • GeoClue integration
    • DHCP timezone option (intlclock bug 523324 )

• system-config-date
  • Can this go away?
  • Where would NTP be configured?
  • Where would "System clock uses UTC" be configured?
    • Need to explain what that means better anyway
  • Should use same timezone widget as intlclock (via libgweather?)

• firstboot
  • Allow user to pick a location, not just a timezone
  • Use location/timezone selection widgets from intlclock (via libgweather?)
  • Possibly do various locale-related tweaks as discussed above

• evolution
  • Should default to using the system timezone. (libgweather has code to figure this out)
  • Should use same timezone widget as intlclock (via libgweather?)
  • Should display appointments using localized timezone names
  • Should use libgweather for weather, and not ship its own Locations.xml file

Test Plan

1. Buy a GPS
2. Travel around the world, spending a few days in each location doing testing
3. Fix bugs encountered, revisit buggy locations to re-test
4. Submit expense report to the

User Experience

1. Users who live somewhere should be able to tell Fedora where they live, and have it set their timezone and weather station appropriately, even if they live somewhere really obscure. Furthermore, they should only need to enter this information once. (Unless they move...)
2. Users who travel with their computers should be able to easily have the computer's timezone and weather indicator "follow" them.
3. Autocompletion in the location entry:
4. Timezone selection:

Dependencies

• GeoClue integration
• Various upstream libgweather bugs, such as timezone localization (529054 ) and improvements to location picking (527593 , 530178 )
• This implements part of FeatureFirstboot , and contrariwise is affected by any changes that they might make to the overall firstboot structure
• This either integrates with or is an alternative to LocalePreferences
• Some work to integrate evolution's timezone picker

Contingency Plan

• Continue using the existing code. Some of the improvements suggested here can be adopted even if others aren't finished.

---