Thank you both for the clarification. I understand better now how locations are decided for inclusion in tzdata; it is not at all to do with size/importance as I had assumed, but about maintaining a minimal set of zones with a single representative city from each one selected to be used as the label. Software should never have to ask a 'regular person' what their timezone is, but instead to ask for their location, and then make use of some kind of location-to-timezone lookup routine. https://developers.google.com/maps/documentation/timezone/intro https://metacpan.org/pod/Geo::Location::TimeZone https://pypi.org/project/timezonefinder/ Cheers JP On 24/11/19 5:35 am, Guy Harris wrote:
On Nov 23, 2019, at 1:10 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 11/22/19 10:06 PM, John Pye wrote:
What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion? The latter. See <https://data.iana.org/time-zones/theory.html#naming>. In particular, this means that people shouldn't look for *their* city, or for the major city nearest to them, if they're looking for the name to use in the tzdb ID setting they want. A lot of people in California, for example, will fail to find America/San_Francisco or America/San_Jose in the database, they'll only find America/Los_Angeles even though they're a lot closer to San Francisco or San Jose than they are to Los Angeles.
User interfaces for selecting a time zone should not rely on the set of tzdb IDs being a comprehensive list of cities.