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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-01-08 09:46:26 | Re: 8.3.0 release schedule (Was:Re: [BUGS] BUG #3852: Could not create complex aggregate) |
Previous Message | Michael Akinde | 2008-01-08 08:50:07 | Re: VACUUM FULL out of memory |