[tz] Reason for removal of several TZ
guy at alum.mit.edu
Mon Dec 4 20:20:55 UTC 2017
On Dec 4, 2017, at 11:52 AM, Michael Douglass <mikeadouglass at gmail.com> wrote:
> This issue always surfaces at one point or another. I and others have argued for a long time that timezone ids should be opaque.
> It's really up to some localization feature to provide meaningful names for those timezones. The data for those localization already exists - providing region/city names for timezones has just led people to believe they mean more than they do.
> I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it.
There are tzdb regions and there are time zones; the two are different - a tzdb region can be in different time zones at different times.
Strings such as Europe/Berlin correspond to tzdb regions. Making those strings opaque would force UIs for selecting the tzdb region to provide something better than a list of tzdb region IDs, or of tzdb region IDs with minimal tweaks such as replacing underscores with spaces, as all too many currently do, and thus also reduce the level of complaints about "why isn't my important city listed?" or "why is this random city used rather than the city that *should* but used?" tzdb region IDs do not need to be localized; they need to be hidden from the UI.
Strings such as WGT and WGST correspond to time zones. Those strings were, back when the tzdb and its sample code were originally created, provided by UN*X APIs, so the sample code - originally developed as a replacement for UN*X time conversion APIs - provided those APIs, and the tzdb provided values for them. *Those* should be localized. and are localized in the CLDR (http://cldr.unicode.org), which also provides long names.
More information about the tz