Re: Add FET to Default and Europe.txt - Mailing list pgsql-hackers
From | Marc Balmer |
---|---|
Subject | Re: Add FET to Default and Europe.txt |
Date | |
Msg-id | 5072A777.6030105@msys.ch Whole thread Raw |
In response to | Re: Add FET to Default and Europe.txt (Simon Riggs <simon@2ndQuadrant.com>) |
Responses |
Re: Add FET to Default and Europe.txt
Re: Add FET to Default and Europe.txt |
List | pgsql-hackers |
Am 08.10.12 11:07, schrieb Simon Riggs: > On 8 October 2012 09:05, Heikki Linnakangas <hlinnakangas@vmware.com> 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 >> http://www.postgresql.org/docs/devel/static/datetime-config-files.html. >> 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 ;)
pgsql-hackers by date: