Andrew Gierth <and...@tao11.riddles.org.uk> writes: > I was planning on submitting a follow-up myself (for pg13+) for > discussion of further improvements. My suggestion would be that we > should have the following order of preference, from highest to lowest:
> - UTC (justified by being an international standard) > - Etc/UTC > - zones in zone.tab/zone1970.tab: > These are the zone names that are intended to be presented to the > user to select from. Dispute the exact meaning as you will, but I > think it makes sense that these names should be chosen over > equivalently good matches just on that basis. > - zones in Africa/ America/ Antarctica/ Asia/ Atlantic/ Australia/ > Europe/ Indian/ Pacific/ Arctic/ > These subdirs are the ones generated by the "primary" zone data > files, including both Zone and Link statements but not counting > the "backward" and "etcetera" files. > - GMT (justified on the basis of its presence as a default in the code) > - Etc/* > - any other zone name with a / > - any zone name without a /, excluding 'localtime' and 'Factory' > - 'localtime' > - 'Factory' TBH, I find this borderline insane: it's taking a problem we did not have and moving the goalposts to the next county. Not just any old county, either, but one where there's a shooting war going on. As soon as you do something like putting detailed preferences into the zone name selection rules, you are going to be up against problems like "should Europe/ have priority over Asia/, or vice versa?" This is not academic; see for example Link Asia/Nicosia Europe/Nicosia Link Europe/Istanbul Asia/Istanbul # Istanbul is in both continents. These choices affect exactly the people who are going to get bent out of shape because you picked the "wrong" name for their zone. Doesn't matter that both names are "wrong" to different subsets. As long as we have a trivial and obviously apolitical rule like alphabetical order, I think we can skate over such things; but the minute we have any sort of human choices involved there, we're going to be getting politically driven requests to do-it-like-this-because-I-think- the-default-should-be-that. Again, trawl the tzdb list archives for awhile if you think this might not be a problem: http://mm.icann.org/pipermail/tz/ I think we can get away with fixing simple cases that are directly caused by tzdb's own idiosyncrasies, ie "localtime" and "posixrules" and "Factory". If we go further than that, we *will* regret it. regards, tom lane