Martijn van Oosterhout <kleptog@xxxxxxxxx> writes: > I really wish we could clear up this stuff with the australian > timezones. I'd love a poll as to how often they're used because I don't > think most people want them. I think defining the problem as "let's get rid of australian_timezones" would be a serious mistake. The basic problem here is that we can't have a one-size-fits-all list of timezone abbreviations. We've certainly heard plenty of complaints about IST, and I seem to recall some from Brazil, and there are other conflicts noted in the comments in the existing list. So even if there is no one who cares anymore about australian_timezones (which I doubt, 'cause that code isn't all that old), we still have a problem. I want to fix it so users can make up their own minds and stop pestering us ;-). (Or more accurately, I want someone else to fix it ... it's not high enough on my own want-list that I'd do it myself soon.) That would cause the australian_timezones parameter in its current form to go away, but it wouldn't simply be a feature-ectomy. > The solution is to allow the timezone portion to be a string like > "Australia/Adelaide" and to leave these three letter timezones behind. While I'd certainly like to see us allow the long forms of timezone names within data input, you're living in a dream world if you think that people will be willing to type, eg, "Americas/New_York" every time where they had been used to entering "EST". We need to support the abbreviations too. regards, tom lane
