Am 08.10.12 11:07, schrieb Simon Riggs:
> On 8 October 2012 09:05, Heikki Linnakangas <> wrote:
>>> * Make the tz file configurable, so people can be more explicit about
>>> what *they* mean by certain codes, to avoid the need for choosing
>>> between countries. For example, someone may have hardcoded particular
>>> codes with the understanding they relate to one particular TZ - if we
>>> make changes, we will alter the application logic, so that must be
>>> able to be "put back" for backwards compatibility.
>> It is configurable. See
>> We're just discussing what the defaults should be.
> The problem there is that the default is "Default", so you have no
> idea what you are accepting and so are unlikely to be brave enough to
> alter it.
> If "default" were named "Postgres9" then people would at least
> understand that hackers had decided a few things and they might want
> to override it.
> So I think we need 2 new settings: one called "Postgres92", one called
> "Postgres93". 93 has the new settings and is the default.
> "Default" would no longer map to anything, to make sure we have an
> explicit break of compatibility.

Removing the timezone abbreviations from the default settings is
probably the wrong approach.  People use them, I use them, and my
original request to add FET came from the fact that someone wanted to
use it.

As long as we have a type "timestamp with timezone", there should also
be a way use and specify timezones in a "usual" format - by default.

I think the problem we face is more of a maintainer nature than of a
technical nature.  Someone has to maintain this information.  But then
all other projects, mostly BSDs, that I was involved with, managed to
keep this information more or less up to date.

A good starting point would be to take the timezone information directly
from the the files IANA distributes, instead of manually copying and
maintaining them in a separate file.  If no one else does, I can try to
maintain these files.  Those who know about my work, know that I do a
lot of time related software (support for time signal receivers in
OpenBSD, e.g.).

So my vote - if I have one - is to keep the TZ information, but maybe
maintain it better, if needed.

Oh, and as a side note, I did not check how often the TZ database gets
updated in PostgreSQL, if someone actually maintains it, I did not want
to imply you do a bad job ;)

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to