On 03/09/2016 05:51 PM, Paul Eggert wrote:
... UTC is supposed to be universal, not local to Europe or to the United Kingdom.
Also said as: UTC is the same everywhere. That is true for every timescale in the tzdb; that does not stop us from identifying them by their geographic origin.
Plus, GMT is not the same as UTC.
Within the scope of the tzdb it is. I believe that the general public also considers them to be synonymous. The Theory file states that tzselect, and indirectly the zone tables, are targeted at inexperienced users. As I see it, there are only two choices: use an existing top level category, or create a new one. I experimented with creating a UTC/UTC file structure, but having a new top level menu entry just for UTC seemed overkill. Actually, you cannot create that exact structure, because of the existing UTC file in the root of TZDIR. There are other complications, what CC to use for it in the zone tables? What Coords? Using Greenwich solves those two questions. Try tzselect with the patch applied. I think you will see it is not so bad. Given the existing choices in top level menu, where would you look for UTC? My answer to that question is based on personal experience. My GPS has a World Clock application and the zone selector is geographically based, just like tzselect. I followed the menus straight to London. As with tzselect, no choice for UTC was offered. I had to settle for Reykjavik. There is one thing about my initial patch that I'm not happy with; creating the link from the 'etcetera' source file. The Theory file says that etcetera can be excluded. I was unsure what the ramifications of duplicating UTC in the 'europe' file would be. Summary questions: Should there be a zone table (tzselect) entry for UTC? Should an existing entry in the top level menu be used, or a new one created? How should the previous choice be implemented?