On Mon, Oct 8, 2012 at 4:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > We can't just refuse to deal with this ambiguity. We have to have some > very-low-pain way to install settings that will please those large > fractions of our user base. Moreover, if that very-low-pain way isn't > the exact same way it's been done for the last half dozen releases, > you'll already have managed to annoy those selfsame large fractions. > You'd better have a good reason for changing it.
As previously noted, there are two topics that are being discussed here: - how to allow users to configure their own timezone abbreviations and - how to keep the timezone abbreviations that we ship updated wrt zic changes Regarding configurability, we currently allow users (=administrators) to change their abbreviations to whatever they like to use. The "Default" file we provide has been taken from the set that used to be a list that we compiled in back in the 8.x days (and we had this egregious GUC "australian_timezones" that decided whether CST/EST was regarded to be US or Australian timezones - there was no such hack for any of the other ambiguities). These timezone abbreviations have developed over several decades, most of these decades without global communication in mind. They are full of inconsistencies and irregularities and IMHO any way to select a proper set for someone automatically is doomed to solve the problem only partially. Another funny ambiguity is that the EST timezone in Austalia could mean both Eastern Standard Time and Eastern Summer Time, having different offsets depending on what month of the year you're in... The fact that we don't hear more complaints about the sets actually suggests that most people are happy with our "Default" set. In fact, Marc could just add his FET timezone to his own installations and use it from there. His request to add it to our Default set however is perfectly valid and should be discussed. One thing that could be improved about configurability is the fact that if you're not an administrator of the database, i.e. if you don't have write access to where the timezones are defined, you're pretty much out of luck being able to define your own abbreviations. This is true in a shared hosting environment for example. Wrt updating the timezone abbreviation files, I guess what we need is a parser for the zic database, our own timezone files and a script that compares the two datasets and spits out any conflicts so that we can clean them up after manual inspection of the differences. I will see if I can come up with some scripts in this direction. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
