Re: A renewed plea for inclusion of zone.tab

Поиск
Список
Период
Сортировка
От Chris Browne
Тема Re: A renewed plea for inclusion of zone.tab
Дата
Msg-id 87prfnjddt.fsf@dba2.int.libertyrms.com
обсуждение исходный текст
Ответ на A renewed plea for inclusion of zone.tab  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
andrew@tao11.riddles.org.uk (Andrew Gierth) writes:
> 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?

I can confirm having recently hit something rather like this...

We wanted to indicate which timezone people were in, but in the
absence of having something like zone.tab conveniently available,
people were starting to talk about designing their own ad-hoc, buggy
version of something looking like about half of zone.tab.

>  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.

Right.  Having zone.tab data available in the DB would be *way* more
convenient, especially in that it is not at all obvious that it's
always available on systems, let alone in a consistent place.

This isn't an argument for "it must be considered standard,
yesterday."  But it's plenty valuable to look to having a way to parse
zone.tab and turn it into a table or two.
-- 
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/linuxxian.html
"The only thing  better than TV with the  sound off is  Radio with the
sound off." -- Dave Moon


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Closing some 8.4 open items
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Closing some 8.4 open items