>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
Tom> So I'm toying with the idea of extending Andrew's patch to put a
Tom> negative preference on "localtime", ensuring we'll use some other
Tom> name for the zone if one is available.
Tom> Also, now that we have this mechanism, maybe we should charge it
Tom> with de-preferencing the old "Factory" zone, removing the
Tom> hard-wired kluge that we currently have for rejecting that.
Tom> (Modern tzdb doesn't install "Factory" at all, but some
Tom> installations might still do so in the service of blind backwards
Tom> compatibility.)
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'
Choosing names with / over ones without is a change from our existing
preference for shorter names, but it's more robust in the face of the
various crap that gets dumped in the top level of the zoneinfo dir.
It could be argued that we should reverse the relative order of UTC vs.
Etc/UTC and likewise for GMT for the same reason, but I think that's
less important.
--
Andrew (irc:RhodiumToad)
