Re: Add FET to Default and Europe.txt

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Add FET to Default and Europe.txt
Дата
Msg-id CA+U5nMK8Daa=_kvLfjtO_2LX=QgYyd9jfZ5EkKjH-u0ZKfRqWg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add FET to Default and Europe.txt  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Add FET to Default and Europe.txt
Список pgsql-hackers
On 6 October 2012 22:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Thus for example "MSK" apparently now means GMT+4 not GMT+3.  We can
> change the tznames entry for that, but should we get rid of "MSD"
> entirely?  Some input from the Russians on this list would be helpful.
...
> Comments?

It shouldn't be our job to make decisions like this on behalf of the world.

The TZ database clearly changes over time, so doing this accurately
would mean we'd need to hold start and stop dates for each code so it
can be used appropriately with specific times. Which would mean
holding data in much finer detail that the source data, which is a
little bizarre.

* We should deprecate all use of timezone abbreviations in our
internal code, if any.

* Ship only the current tz file, as shipped by IANA with as few prep
steps as possible

* 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.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: 64-bit API for large object
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Rethinking placement of latch self-pipe initialization