Re: Add FET to Default and Europe.txt

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marc Balmer <marc(at)msys(dot)ch>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add FET to Default and Europe.txt
Date: 2012-10-08 07:03:17
Message-ID: CA+U5nMK8Daa=_kvLfjtO_2LX=QgYyd9jfZ5EkKjH-u0ZKfRqWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6 October 2012 22:40, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-10-08 07:12:12 Re: Rethinking placement of latch self-pipe initialization
Previous Message Amit Kapila 2012-10-08 05:00:40 Re: 64-bit API for large object