Обсуждение: Re: [PATCHES] Time zone definitions to config files
David Fetter <david@fetter.org> writes: > On Mon, Jul 24, 2006 at 11:59:34PM -0400, Tom Lane wrote: >> The documentation is still in need of help ... in particular, Table >> B-4 (timezone names) is now out of sync with reality. > I'll take a whack at that patch this evening PDT or tomorrow evening > at the latest. We're too late in the cycle to go over this, but maybe > we can figure out a way to have this data read from the same data > source as the pg_timezones VIEW does at compile time. Keeping two > such table in synch seems error-prone. Well, the problem is exactly that there is no "same data source" anymore: the local DBA can customize the timezone list all he wants. We could document what the out-of-the-box settings are, but is it really useful to duplicate that info in the SGML docs? We don't for example provide a copy of psql \df+ output in the SGML docs, and I'm wondering if this isn't kind of the same animal. regards, tom lane
On Tue, Jul 25, 2006 at 10:37:20PM -0400, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > > I'll take a whack at that patch this evening PDT or tomorrow evening > > at the latest. We're too late in the cycle to go over this, but maybe > > we can figure out a way to have this data read from the same data > > source as the pg_timezones VIEW does at compile time. Keeping two > > such table in synch seems error-prone. > Well, the problem is exactly that there is no "same data source" > anymore: the local DBA can customize the timezone list all he wants. > We could document what the out-of-the-box settings are, but is it > really useful to duplicate that info in the SGML docs? We don't > for example provide a copy of psql \df+ output in the SGML docs, > and I'm wondering if this isn't kind of the same animal. I'd vote for not including it. The current table is way out of sync already. I first chose the timezones for the "Default"-set based on this table in the docs but then I noticed that the table does not really reflect the timezones in the source code. With the view it's now almost trivial to keep both synced but it still is a source of errors. Furthermore since nobody has complained about the incorrect table so far, I don't think many people care. And those who do can easily consult the view or the file of the Default set directly. Joachim