On Dec 11, 2019, at 3:14 PM, Marc Sackeli <marc.sackeli@gmail.com> wrote:
If this is a potential outcome, is there an idea of how the tz database would adapt to this change? My guess is that new entries would be created to allow us to delineate between these states.
Yes.
We are currently covered if California decides to change thanks to America/Los_Angeles, but what if Oregon or Tennessee decides they want to change? Does this mean America/Portland and America/Nashville would be created?
Yes.
Or perhaps America/Oregon and America/Tennessee?
No. ftp://ftp.iana.org/tz/tzdb-2018g/theory.html "Names of timezones Each timezone has a unique name. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like "Ruthenia" instead of the timezone name "Europe/Uzhgorod". If geolocation information is available, a selection interface can locate the user on a timezone map or prioritize names that are geographically close. For an example selection interface, see the tzselect program in the tz code. The Unicode Common Locale Data Repository contains data that may be useful for other selection interfaces; it maps timezone names like Europe/Uzhgorod to CLDR names like uauzh which are in turn mapped to locale-dependent strings like "Uzhhorod", "Ungvár", "Ужгород", and "乌日哥罗德". The naming conventions attempt to strike a balance among the following goals: • Uniquely identify every timezone where clocks have agreed since 1970. This is essential for the intended use: static clocks keeping local civil time. • Indicate to experts where the timezone's clocks typically are. • Be robust in the presence of political changes. For example, names of countries are ordinarily not used, to avoid incompatibilities when countries change their name (e.g., Zaire→Congo) or when locations change countries (e.g., Hong Kong from UK colony to China). • Be portable to a wide variety of implementations. • Use a consistent naming conventions over the entire world. Names normally have the form AREA/LOCATION, where AREA is a continent or ocean, and LOCATION is a specific location within the area. North and South America share the same area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York', and 'Pacific/Honolulu'. Some names are further qualified to help avoid confusion; for example, 'America/Indiana/Petersburg' distinguishes Petersburg, Indiana from other Petersburgs in America. Here are the general guidelines used for choosing timezone names, in decreasing order of importance: • Use only valid POSIX file name components (i.e., the parts of names other than '/'). Do not use the file name components '.' and '..'. Within a file name component, use only ASCIIletters, '.', '-' and '_'. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with '-'. E.g., prefer Asia/Brunei to Asia/Bandar_Seri_Begawan. Exceptions: see the discussion of legacy names below. • A name must not be empty, or contain '//', or start or end with '/'. • Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case. • If one name A is an initial prefix of another name AB (ignoring case), then B must not start with '/', as a regular file cannot have the same name as a directory in POSIX. For example, America/New_York precludes America/New_York/Bronx. • Uninhabited regions like the North Pole and Bouvet Island do not need locations, since local time is not defined there. • There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory. • If all the clocks in a timezone have agreed since 1970, do not bother to include more than one timezone even if some of the clocks disagreed before 1970. Otherwise these tables would become annoyingly large. • If a name is ambiguous, use a less ambiguous alternative; e.g., many cities are named San José and Georgetown, so prefer America/Costa_Rica to America/San_Jose and America/Guyana to America/Georgetown. • Keep locations compact. Use cities or small islands, not countries or regions, so that any future changes do not split individual locations into different timezones. E.g., prefer Europe/Paris to Europe/France, since France has had multiple time zones. • Use mainstream English spelling, e.g., prefer Europe/Rome to Europa/Roma, and prefer Europe/Athens to the Greek Ευρώπη/Αθήνα or the Romanized Evrópi/Athína. The POSIX file name restrictions encourage this guideline. • Use the most populous among locations in a region, e.g., prefer Asia/Shanghai to Asia/Beijing. Among locations with similar populations, pick the best-known location, e.g., prefer Europe/Rome to Europe/Milan. • Use the singular form, e.g., prefer Atlantic/Canary to Atlantic/Canaries. • Omit common suffixes like '_Islands' and '_City', unless that would lead to ambiguity. E.g., prefer America/Cayman to America/Cayman_Islands and America/Guatemala toAmerica/Guatemala_City, but prefer America/Mexico_City to America/Mexico because the country of Mexico has several time zones. • Use '_' to represent a space. • Omit '.' from abbreviations in names. E.g., prefer Atlantic/St_Helena to Atlantic/St._Helena. • Do not change established names if they only marginally violate the above guidelines. For example, do not change the existing name Europe/Rome to Europe/Milan merely because Milan's population has grown to be somewhat greater than Rome's. • If a name is changed, put its old spelling in the 'backward' file. This means old spellings will continue to work." In particular, note Keep locations compact. Use cities or small islands, not countries or regions, so that any future changes do not split individual locations into different timezones. E.g., prefer Europe/Paris to Europe/France, since France has had multiple time zones.