On Mon, Oct 8, 2012 at 4:26 PM, Tom Lane wrote:
> for instance IST (the Indians and the Israelis both use this, but not to
> mean the same thing).
And Ireland btw.
So I'm not sure if this goes anywhere but could we get away with
picking the timezone with the matching abbreviation closest to
On Mon, Oct 8, 2012 at 4:00 PM, Tom Lane wrote:
> We can't just refuse to deal with this ambiguity. We have to have some
> very-low-pain way to install settings that will please those large
> fractions of our user base. Moreover, if that very-low-pain way isn't
> the exact same way it's been don
Christopher Browne writes:
> The scenario where we could unambiguously include time zones is where
> the symbols are unique. If we were to include *all* uniquely-named
> symbols, that would minimize the number of complaints about missing
> zones, whilst evading the cases where the symbols are non
On Mon, Oct 8, 2012 at 11:54 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 08.10.2012 18:26, Tom Lane wrote:
>>> The other thing that the abbreviation list files are doing for us is
>>> providing a user-configurable way to resolve conflicting abbreviations,
>>> for instance IST (the Indi
Heikki Linnakangas writes:
> On 08.10.2012 18:26, Tom Lane wrote:
>> The other thing that the abbreviation list files are doing for us is
>> providing a user-configurable way to resolve conflicting abbreviations,
>> for instance IST (the Indians and the Israelis both use this, but not to
>> mean t
On 08.10.2012 18:26, Tom Lane wrote:
The other thing that the abbreviation list files are doing for us is
providing a user-configurable way to resolve conflicting abbreviations,
for instance IST (the Indians and the Israelis both use this, but not to
mean the same thing). This requirement isn't
Simon Riggs writes:
> Sorry for any confusion. I've not suggested removing timezone
> abbreviations, nor do I wish to do so.
> I did suggest that we do not rely upon TZ abbreviations in any code
> shipped by PostgreSQL project, but I suspect that is a non-problem
> anyway.
No, we don't rely on t
On Mon, Oct 8, 2012 at 05:15:18PM +0200, Marc Balmer wrote:
> Am 08.10.12 16:53, schrieb Bruce Momjian:
> > On Mon, Oct 8, 2012 at 12:14:15PM +0200, Marc Balmer wrote:
> >> A good starting point would be to take the timezone information directly
> >> from the the files IANA distributes, instead o
Am 08.10.12 16:53, schrieb Bruce Momjian:
> On Mon, Oct 8, 2012 at 12:14:15PM +0200, Marc Balmer wrote:
>> 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
On Mon, Oct 8, 2012 at 11:10:08AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Could we pull an abbreviation list from one of the BSDs?
>
> And that would be authoritative why?
It would be somone else maintaining it. :-)
--
Bruce Momjian http://momjian.us
EnterpriseDB
Bruce Momjian writes:
> Could we pull an abbreviation list from one of the BSDs?
And that would be authoritative why?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Mon, Oct 8, 2012 at 12:14:15PM +0200, Marc Balmer wrote:
> 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 f
On 8 October 2012 11:14, Marc Balmer wrote:
>> 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.
>
> Remov
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 hardc
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
On 08.10.2012 10:03, Simon Riggs wrote:
On 6 October 2012 22:40, Tom Lane 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.
...
C
On 6 October 2012 22:40, Tom Lane 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
I wrote:
> What the README file actually suggests is that periodically we should
> re-evaluate the set of default abbreviations.
I looked through the diffs between the 2005m Olson time zone files
(which is what we were using at the time the tznames files were created)
and current. There are sever
Marc Balmer writes:
> These files are maintained by PostgreSQL, there is even a README with an
> explicit mention that changes should be reported to pgsql-hackers
What the README file actually suggests is that periodically we should
re-evaluate the set of default abbreviations. I'm not that
On Sat, Oct 6, 2012 at 02:46:03PM +0200, Marc Balmer wrote:
> Bruce,
>
> > The Postgres community does not maintain the timezone database; we ship
> > copies of the IANA timezone database; you will have to request the
> > changes from them:
> >
> > http://www.iana.org/time-zones
>
> Pleas
Bruce,
> The Postgres community does not maintain the timezone database; we ship
> copies of the IANA timezone database; you will have to request the
> changes from them:
>
> http://www.iana.org/time-zones
Please take a second look at the diffs, they do *NOT* change the files
in the time
The Postgres community does not maintain the timezone database; we ship
copies of the IANA timezone database; you will have to request the
changes from them:
http://www.iana.org/time-zones
---
On Sat, Oct 6, 2012
22 matches
Mail list logo
