<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi, long time lurker here, finally throwing my voice into the ring.</div><div class=""><br class=""></div>This is a follow-up to the “Time Zone City for China” thread a week ago (starting at&nbsp;<a href="http://mm.icann.org/pipermail/tz/2015-July/022480.html" class="">http://mm.icann.org/pipermail/tz/2015-July/022480.html</a>&nbsp;). What particularly caught my attention was the discussion about the use of time zone IDs in user interfaces.<div class=""><br class=""></div><div class="">Paul Eggert: "The string 'Asia/Shanghai' is a tzdata-specific identifier, not intended to be visible to non-experts.”</div><div class=""><br class=""></div><div class="">Guy Harris: "Several time zone selectors I've seen are lazily-written crap that either directly display the tzdb name or tweak it slightly by, for example, splitting it into continent and city and displaying them in a more "user-friendly" form.”</div><div class=""><br class=""></div><div class="">Guy Harris: “&gt; Looks like this logic is not well understood by the communities.</div><br class="">Then we need to do a better job of explaining it to them.”<div class=""><br class=""></div><div class=""><br class=""></div><div class="">Not to put too fine a point on it… Yes, there needs to be a better job done of explaining that the city names in time zone IDs should not be used in user interfaces.</div><div class=""><br class=""></div><div class="">After reading that discussion I went looking through the tzdb files for guidance around the use of IDs in UIs. All I managed to find was this snippet in the Theory file, on line 385:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">This naming convention is not intended for use by inexperienced users</div><div class="">to select TZ values by themselves (though they can of course examine</div><div class="">and reuse existing settings). &nbsp;Distributors should provide</div><div class="">documentation and/or a simple selection interface that explains the</div><div class="">names; see the 'tzselect' program supplied with this distribution for</div><div class="">one example.</div></div></blockquote><div class=""><br class=""></div><div class="">Given that the above snippet is around halfway through the file – and its wording still provides a fair bit of leeway – it’s not exactly enforcing the stronger opinions displayed on this list about how the IDs should be used.</div><div class=""><br class=""></div><div class="">For some context, my domain knowledge is restricted to web sites/applications, so I can’t speak to the OS-level discussions in the previous thread. What I do know is how web developers deal with time zones, if they deal with them at all. For the most part, they use a library specific to their language of choice which slightly abstracts the tzdb data. There are two things these libraries have in common:</div><div class=""><br class=""></div><div class="">1. They use tzdb zone identifiers as the primary part of their API.</div><div class="">2. They don’t have any mentions in their documentation that these identifiers are not for public display.</div><div class=""><br class=""></div><div class="">This is not me picking on time zone library authors, as I know that some of them are on this mailing list. My main point is that web developers are, for the most part, so abstracted from the tzdb source that the zone IDs are the only interface they know. Therefore the IDs are what they put in their selection UIs.</div><div class=""><br class=""></div><div class="">There’s also the not-insignificant matter of localisation of display names (even Moment Timezone, referenced in tz-link.htm, notes in its API documentation: "Because these strings are generally localized, Moment Timezone does not provide any long names for zones.”). Personally, I didn’t know of the existence of CLDR until I started reading this mailing list.</div><div class=""><br class=""></div><div class="">So, instead of dismissing zone-IDs-in-a-user-interface as “lazily written crap”, how about we:</div><div class=""><br class=""></div><div class="">a) Acknowledge that most web-based UIs for picking time zones are written by developers who genuinely don’t know any better (I count my past self in this category)</div><div class="">b) Make an effort to better educate them about recommended uses of the IDs.</div><div class=""><br class=""></div><div class="">I am not intending for this to come across as antagonistic or facetious. I just genuinely want the quality of time zone selectors on the web to improve.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Gil</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>