>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
> David Fetter <da...@fetter.org> writes:
>> On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
>>> I still see no point in this unless we expose the information in
>>> pg_timezone_names, which requires rather more than a one-line patch.
>> There's really no point, and a lot of good stuff lost,
Tom> Like what? I do not actually believe that anyone needs an
Tom> interactive geographical timezone selector based on
Tom> pg_timezone_names.
As the bard said, "There are more things in heaven and earth, Horatio,
than are dreamed of in your philosophy."
Having been involved in writing an app that would have used exactly
such a thing had it been available, I find your disbelief somewhat ...
unpersuasive. The frequency with which the topic comes up on IRC is
also significant (it's not a multiple-times-per-week thing like window
functions or LATERAL, but it's often enough to be noticed).
The usual conversation goes something like this (generally following
on from some discussion of how to do timezone conversions):
Q: how do I get the list of available zone names?
A: see pg_timezone_names
Q: but there's 1650/1400/560/452 [delete as applicable] entries in
there! how do I know which one to use for any given user? Can I
work it out from the user's location?
A: Some locations have timezones that vary by county level, so it's
hard to automate unless you have a street address and detailed
maps/database of Indiana and other awkward places. Best bet is to
ask the user themselves, once you know what country they're in.
Q: How do you know what zones are in what countries?
A: that info is in zone.tab, which you can find either from your OS's
timezone directory or from the postgres source for your postgres
version. Put that data in a table or something and use it to prompt
the user; it has text to help disambiguate the obscure cases.
Q: ... wtf? why is that not installed anywhere?
Tom> Any such application is far more likely to be looking at the
Tom> system tzdata files.
Only if it's using the system TZ functions to do conversions rather
than doing them inside pg, which certainly isn't how _I'd_ recommend
an app writer do it.
Tom> In any case it would need a lot more data that we aren't
Tom> supplying (like, say, a world map...)
Nope. While I'm sure someone has a use for the lat/long stuff, the
more likely approach is just to select the zone names and explanatory
text for the country of interest, and let the user select a zone. No
extra data needed.
Tom> My fundamental objection here is that we'd be permanently
Tom> widening the API we have to support for timezones, which could
Tom> come back to haunt us. I will agree that it's not too likely
Tom> upstream would stop supporting zone.tab entirely, but it's quite
Tom> likely they could change the format or further complicate its
Tom> relationship to the actual zone list. I don't wish to buy into
Tom> that without a more credible argument that there are actual
Tom> database applications that need this data.
zone.tab doesn't become part of the API any more than the actual
content of timezone/America/New_York is part of the API. It is up to
whoever is providing an interface to access that data to cope with
any changes in format.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
