Martijn van Oosterhout <kleptog@svana.org> 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
