Skip site navigation (1) Skip section navigation (2)

Re: Data from zone.tab

From: Naz Gassiep <naz(at)mira(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Data from zone.tab
Date: 2008-01-08 09:02:03
Message-ID: 47833C0B.5070807@mira.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Sorry to reply, but there should also be a field in the system view  
"is_alias" so that devs are able to tell which zone names are in the 
zone.tab file and which are not. That way a perfect 1:1 mapping between 
zone.tab and app can be made. If this were done then it'd make things 
like using CLDR data and other standardized data sources easier, as you 
could be confident that all timezone names matched the data in the CLDR.

I think what I'm trying to say is that using and applying standards is a 
good thing.

- Naz.

Naz Gassiep wrote:
> Is there any reason that the zone.tab information is not included in 
> the pg_timezone_names system view? ISTM that there is really no reason 
> not to, as that view is really populated using that file anyway. There 
> is a 1:1 mapping (assuming the aliases are mapped to the zone.tab 
> entries they are aliases of) of entries in that view with enties in 
> zone.tab.
>
> Reading an earlier thread on this matter, I think Magnus is behind the 
> code that generates the view. What are the chances of getting at least 
> the country code included in the pg_timezone_names system view? It'd 
> really help out with i18n / L10n work, and given that PG already ships 
> with that data present, it seems silly to not take advantage of it 
> given how easy it would be to do so.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

In response to

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2008-01-08 09:46:26
Subject: Re: 8.3.0 release schedule (Was:Re: [BUGS] BUG #3852: Could not create complex aggregate)
Previous:From: Michael AkindeDate: 2008-01-08 08:50:07
Subject: Re: VACUUM FULL out of memory

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group