[tz] [PATCH] Revert recent pre-1970 changes.

Guy Harris guy at alum.mit.edu
Mon Sep 2 18:26:33 UTC 2013


On Sep 2, 2013, at 3:19 AM, Lester Caine <lester at lsces.co.uk> wrote:

> Guy Harris wrote:
>>> Since the ISO-3166-1 code table is a reasonably well used base for most
>>> geographical activity, at some point timezones are required to match each.
>> 
>> There is no necessarily a single tzdb zone for a given entity that has an ISO
>> 3166 code.  (Two immediately obvious counterexamples - the entities with the
>> ISO 3166 codes "US" and "CA".)
>> 
>> So do you mean that there do not exist - or, at least,*should*  not exist -
>> any tzdb zones that apply to more than one entity with a given ISO 3166
>> code?
> 
> Ignoring the politics ... We need to find out from our users what time zone they
> are in.

You need to find out from the system what time zone the user is in.

For UN*X systems that sit in a machine room:

	Users will probably have the time zone in which that machine room resides made the default setting for their session.  That time zone setting was made when the system was set up by the person who set it up.

	For local users, that's almost certainly the right answer, the only exceptions being users at sites sitting on time zone boundaries in offices on the other side of the time zone boundary from the machine room.

	For remote users, their time zone setting might be sent over the connection to the machine, although that didn't seem to be the case when I did "TZ=Europe/Berlin ssh {my machine}" - but the "Europe/Berlin" might have gone over the connection but been ignored or discarded.

	In those cases where the user needs to override the default, they're probably not going to be asked; instead, they're probably going to be obliged to set it themselves.

For UN*X systems that sit on a desktop:

	Systems within an organization may well have been set up by the organization's IT department and given a default time zone setting.  There is also Eliot's and Paul's DHCP option:

		http://tools.ietf.org/html/rfc4833

	although I don't know what DHCP clients or servers support it.

	Personal systems will probably ask the user for the time zone when they set the system up.

For UN*X systems that you can carry with you:

	They can often determine their location, and thus their time zone, using a combination of GPS (if available), Wi-Fi and some database of Wi-Fi networks (if available), and mobile phone tower information (if available).  OS X and iOS are an existence proof of that (and, as I think iMacs come with Wi-Fi, that probably works for most OS X systems that sit on a desktop, too).

	If none of those *are* available, or if the user wants to override it, there's typically a way to set the time zone.

I'm less familiar with Windows, but many of the answers might be similar.

> Asking them 'which continent' is one of those things that gets a blank
> look at times, so even 'Europe' 'London' CAN be confusing to some users. Ask
> them 'country' and you have a much better chance of getting a response, so CA or
> US at least get us to a subset of options to select from? I have no problem if
> the detail is stored under one 'tag' so that both CA and US could use the same raw data, so 'links' to a valid set of tags should work, except would a Canadian know the correct US city? Move to the Far East, and translations become essential and there may be a need for additional 'links'?

The way the OS X "set your time zone" GUI works is that (if you don't have "Set time zone automatically using current location" checked), the world map it shows will, as you move the mouse over it, show vertical bands (probably roughly corresponding to "time zones" in the conventional sense rather than in the "tzdb zone" sense, i.e. representing default offset from GMT but *not* DST rules) and showing the countries in that zone as lighter grey.

If you click on the map, it puts a blue blob at the location of the nearest city to where you clicked, changes the text for "Time Zone:" to a name for the time zone for the city, and puts the name of the city in the "Nearest City:" box.  That box has a drop-down list of cities in the area (perhaps all the cities in that zone).  That's how you select a tzid.

The map says "Geonames.org", which is probably the source of most of the data for the map.  I'm not finding an immediately-obvious indication that the GeoNames database has tzids for locations, so I'm not sure where the tzid for the location comes from.

(Deborah, please feel free to step in if I got anything wrong.  I didn't spend much time looking at that from down in the CoreOS engine room. :-))

So what I think "select a tzid" UIs should do is have a database such as that, and hide tzid strings from the user to the maximum extent possible.  tzselect is a simple version of that, for the command line; fancier command-line tools, with fancier databases than zone.tab, could also be done.

This would, ideally, involve showing people country and city *names* (rather than showing, for example, ISO 3166 country codes), in their own languages, as necessary, and would not involve people ever having to know tzids.


More information about the tz mailing list