On Mon, Feb 6, 2017 at 12:44 PM, Igal @ Lucee.org <igal@lucee.org> wrote:
Tom,
Thank you for your reply: On 2/6/2017 12:18 PM, Tom Lane wrote:
This is controlled by the timezone_abbreviations file, which if
you haven't changed it lists:
# CONFLICT! BST is not unique
# Other timezones:
# - BST: Bougainville Standard Time (Papua New Guinea)
BST 3600 D # British Summer Time # (Europe/London)
I haven't changed any of the config files. I can not find that file on my system (maybe it's in the source code only).
I am using the Red Hat distribution: PostgreSQL 9.6.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4), 64-bit
pg_timezone_names shows the *current* abbreviation for the zone in question
I'm not sure what you mean by "current". If this is not an issue then that's fine, you can ignore this message. It just seemed weird to me that pg_timezone_names and pg_timezone_abbrevs showed very different results for the same code.
"Current" in this context means the abbreviation in effect at the current time. In other words, if I were to look at my current time zone abbreviation it would currently be PST (Pacific Standard time) but in a couple months it would be PDT so the *view* will change depending on the time of year.
It's important to note that there is no BST timezone. That is an abbreviation for a timezone *offset*. Where I live we could be in PST (-08) or PDT (-07). Currently we are in standard time but I could ask for the current time in daylight time and PostgreSQL will give me the current point in time with a PDT or -07 offset. Compounding the problem is the fact that abbreviations are not globally unique. Both the United States and Australia have Eastern and Central Standard and Daylight times, for example.
A timezone, on the other hand, encapsulates the offset as it changes both throughout the year and historically. It is almost always preferable to use an actual timezone by specifying it by name as in Europe/London, America/Los_Angeles, etc.