Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-09 Thread Greg Stark
On Mon, Oct 8, 2012 at 4:26 PM, Tom Lane t...@sss.pgh.pa.us 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 the
system timezone?


-- 
greg


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Simon Riggs
On 6 October 2012 22:40, Tom Lane t...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Heikki Linnakangas

On 08.10.2012 10:03, Simon Riggs wrote:

On 6 October 2012 22:40, Tom Lanet...@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.


I wish it wasn't, too. But I don't think there's any upstream for this 
information. The tz library has abbreviations for timezones, but they're 
not unique.



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


- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Simon Riggs
On 8 October 2012 09:05, Heikki Linnakangas hlinnakan...@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.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Marc Balmer
Am 08.10.12 11:07, schrieb Simon Riggs:
 On 8 October 2012 09:05, Heikki Linnakangas hlinnakan...@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 ;)




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Simon Riggs
On 8 October 2012 11:14, Marc Balmer m...@msys.ch 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.

 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.

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.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Tom Lane
Bruce Momjian br...@momjian.us 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/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Bruce Momjian
On Mon, Oct  8, 2012 at 11:10:08AM -0400, Tom Lane wrote:
 Bruce Momjian br...@momjian.us 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  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Marc Balmer
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 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.).
 
 Could we pull an abbreviation list from one of the BSDs?

Imo, the data should be pulled from the official source.  Else an
unneeded dependency from BSD is likely created...




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Bruce Momjian
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 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.).
  
  Could we pull an abbreviation list from one of the BSDs?
 
 Imo, the data should be pulled from the official source.  Else an
 unneeded dependency from BSD is likely created...

I thought there was no official source of abbreviations that deals with
duplicates by choosing the most appropriate one.  Is there?  Where is
it?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com 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 them AFAIK; certainly we don't use them in data
output.  But people expect to be able to use them in data input.

The idea of tracking date ranges in which a TZ abbreviation is valid
is an interesting one, but it's vastly more effort than I for one
am willing to put into the problem --- not just in coding the
infrastructure, but gathering and maintaining the source data.
[ reflects for a bit... ]  I guess in principle we could pull change
information out of the IANA database rather than having to maintain it
ourselves.  But still what you're suggesting is an awful lot of work.

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 ever going to go away.

The Default list represents some considered judgements as to what the
most widely useful set of abbreviations is.  We don't get to abdicate
the position of having to make those judgements; nobody would thank us
for breaking their database configurations because we can't decide.

I still think that we need some input from actual Russians as to what
is the currently most useful set of abbreviations for Russian time
zones.  Armchair speculation from the other side of the globe isn't
going to be helpful to them.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Heikki Linnakangas

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 ever going to go away.


Locale-specific abbreviation lists would be nice. While abbreviations 
are not unique globally, they have established meanings in particular 
countries and regions. For example, IST is not unique, but if you are in 
India (en_IN) and spell out IST, you probably mean Indian Standard time.


- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Tom Lane
Heikki Linnakangas hlinnakan...@vmware.com 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 the same thing).  This requirement isn't ever going to go away.

 Locale-specific abbreviation lists would be nice.

Yeah, that's a good thought, although the lack of standardization of
locale names seems to make it a bit hard to implement.  My first idea
was look for a tznames file matching the value of LC_TIME, and if
found, concatenate its contents with 'Default'.  But there are enough
ways to spell en_IN to make that a bit problematic, and besides which
a user in India might well be running with C locale anyway.  Still,
there might be a useful incremental usability gain there.

We aren't ever going to get out of the need for user configurability
though.  For instance, if a user in India writes EST, is he thinking
of the Australian or American meaning?  It's plausible that either might
be preferred, depending on who that user interacts with regularly.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Christopher Browne
On Mon, Oct 8, 2012 at 11:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Heikki Linnakangas hlinnakan...@vmware.com 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 the same thing).  This requirement isn't ever going to go away.

 Locale-specific abbreviation lists would be nice.

 Yeah, that's a good thought, although the lack of standardization of
 locale names seems to make it a bit hard to implement.  My first idea
 was look for a tznames file matching the value of LC_TIME, and if
 found, concatenate its contents with 'Default'.  But there are enough
 ways to spell en_IN to make that a bit problematic, and besides which
 a user in India might well be running with C locale anyway.  Still,
 there might be a useful incremental usability gain there.

 We aren't ever going to get out of the need for user configurability
 though.  For instance, if a user in India writes EST, is he thinking
 of the Australian or American meaning?  It's plausible that either might
 be preferred, depending on who that user interacts with regularly.

That sounds pretty cool, but coolness isn't the right way to
evaluate whether this is good or not.

If we introduce cases where peoples' expectations are liable to be
disappointed (e.g. - they get the wrong EST, and report a bug on
that), then we lose.

We have, in effect, been treating the handling of time zones in a
manner where we're imagining there's general agreement on their
interpretation.  We presently get bug reports (and are
losing/getting it not as right as would be nice) in cases where we
leave TZ symbols out, where they could have been included.

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-unique.
That might be worth considering, though it'll certainly attract
complaints in that some odd-ball zones would be included whilst
well-known ones wouldn't.

I would tend to think that local variations (e.g. - having a list for
LC_TIME=en_IN) heads us into a morass of complexity.  As you suggest,
two different people using en_IN might have different preferences for
what EST should mean.

That being said, if we had a way to configure preferred localizations,
people could set up their own set of associations.  You want your own
morass?  You can build it yourself...
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, How would the Lone Ranger handle this?


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Tom Lane
Christopher Browne cbbro...@gmail.com 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-unique.
 That might be worth considering, though it'll certainly attract
 complaints in that some odd-ball zones would be included whilst
 well-known ones wouldn't.

That sounds good in the abstract ... however, consider that two of the
ambiguous abbreviations are EST and CST, which means that taking a hard
line would piss off every American east of the Mississippi, likewise
over half of Canada, not to mention some proportion of Australians.
Can you say user revolt?  Projects have been forked for less.

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 done for the last half dozen releases,
you'll already have managed to annoy those selfsame large fractions.
You'd better have a good reason for changing it.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-08 Thread Joachim Wieland
On Mon, Oct 8, 2012 at 4:00 PM, Tom Lane t...@sss.pgh.pa.us 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 done for the last half dozen releases,
 you'll already have managed to annoy those selfsame large fractions.
 You'd better have a good reason for changing it.

As previously noted, there are two topics that are being discussed here:

- how to allow users to configure their own timezone abbreviations
and
- how to keep the timezone abbreviations that we ship updated wrt zic changes

Regarding configurability, we currently allow users (=administrators)
to change their abbreviations to whatever they like to use. The
Default file we provide has been taken from the set that used to be
a list that we compiled in back in the 8.x days (and we had this
egregious GUC australian_timezones that decided whether CST/EST was
regarded to be US or Australian timezones - there was no such hack for
any of the other ambiguities).

These timezone abbreviations have developed over several decades, most
of these decades without global communication in mind. They are full
of inconsistencies and irregularities and IMHO any way to select a
proper set for someone automatically is doomed to solve the problem
only partially.

Another funny ambiguity is that the EST timezone in Austalia could
mean both Eastern Standard Time and Eastern Summer Time, having
different offsets depending on what month of the year you're in...

The fact that we don't hear more complaints about the sets actually
suggests that most people are happy with our Default set. In fact,
Marc could just add his FET timezone to his own installations and use
it from there. His request to add it to our Default set however is
perfectly valid and should be discussed.

One thing that could be improved about configurability is the fact
that if you're not an administrator of the database, i.e. if you don't
have write access to where the timezones are defined, you're pretty
much out of luck being able to define your own abbreviations. This is
true in a shared hosting environment for example.


Wrt updating the timezone abbreviation files, I guess what we need is
a parser for the zic database, our own timezone files and a script
that compares the two datasets and spits out any conflicts so that we
can clean them up after manual inspection of the differences. I will
see if I can come up with some scripts in this direction.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Add FET to Default and Europe.txt

2012-10-06 Thread Marc Balmer
The attached patch would add the FET timezone abbreviation to the
Default list _and_ the list of european abbreviations.

- mb
diff --git a/src/timezone/tznames/Default b/src/timezone/tznames/Default
index 1369f47..7223ce5 100644
--- a/src/timezone/tznames/Default
+++ b/src/timezone/tznames/Default
@@ -615,6 +615,8 @@ EETDST  10800 D  # East-Egypt Summertime
  # (Europe/Uzhgorod)
  # (Europe/Vilnius)
  # (Europe/Zaporozhye)
+FET 10800# Further-eastern European Time
+ # (Europe/Minsk)
 MEST 7200 D  # Middle Europe Summer Time (not in zic)
 MET  3600# Middle Europe Time (not in zic)
 METDST   7200 D  # Middle Europe Summer Time (not in zic)
diff --git a/src/timezone/tznames/Europe.txt b/src/timezone/tznames/Europe.txt
index 88abecca..6c35ab1 100644
--- a/src/timezone/tznames/Europe.txt
+++ b/src/timezone/tznames/Europe.txt
@@ -154,6 +154,8 @@ EETDST  10800 D  # East-Egypt Summertime
  # (Europe/Uzhgorod)
  # (Europe/Vilnius)
  # (Europe/Zaporozhye)
+FET 10800# Further-eastern European Time
+ # (Europe/Minsk)
 GMT 0# Greenwich Mean Time
  # (Africa/Abidjan)
  # (Africa/Bamako)

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-06 Thread Bruce Momjian

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 at 11:18:43AM +0200, Marc Balmer wrote:
 The attached patch would add the FET timezone abbreviation to the
 Default list _and_ the list of european abbreviations.
 
 - mb

 diff --git a/src/timezone/tznames/Default b/src/timezone/tznames/Default
 index 1369f47..7223ce5 100644
 --- a/src/timezone/tznames/Default
 +++ b/src/timezone/tznames/Default
 @@ -615,6 +615,8 @@ EETDST  10800 D  # East-Egypt Summertime
   # (Europe/Uzhgorod)
   # (Europe/Vilnius)
   # (Europe/Zaporozhye)
 +FET 10800# Further-eastern European Time
 + # (Europe/Minsk)
  MEST 7200 D  # Middle Europe Summer Time (not in zic)
  MET  3600# Middle Europe Time (not in zic)
  METDST   7200 D  # Middle Europe Summer Time (not in zic)
 diff --git a/src/timezone/tznames/Europe.txt b/src/timezone/tznames/Europe.txt
 index 88abecca..6c35ab1 100644
 --- a/src/timezone/tznames/Europe.txt
 +++ b/src/timezone/tznames/Europe.txt
 @@ -154,6 +154,8 @@ EETDST  10800 D  # East-Egypt Summertime
   # (Europe/Uzhgorod)
   # (Europe/Vilnius)
   # (Europe/Zaporozhye)
 +FET 10800# Further-eastern European Time
 + # (Europe/Minsk)
  GMT 0# Greenwich Mean Time
   # (Africa/Abidjan)
   # (Africa/Bamako)

 
 -- 
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers


-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-06 Thread Marc Balmer
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 timezone database, they change the Default set ot timezones that
PostgreSQL uses.

These files are maintained by PostgreSQL, there is even a README with an
explicit mention that changes should be reported to pgsql-hackers



 
 ---
 
 On Sat, Oct  6, 2012 at 11:18:43AM +0200, Marc Balmer wrote:
 The attached patch would add the FET timezone abbreviation to the
 Default list _and_ the list of european abbreviations.

 - mb
 
 diff --git a/src/timezone/tznames/Default b/src/timezone/tznames/Default
 index 1369f47..7223ce5 100644
 --- a/src/timezone/tznames/Default
 +++ b/src/timezone/tznames/Default
 @@ -615,6 +615,8 @@ EETDST  10800 D  # East-Egypt Summertime
   # (Europe/Uzhgorod)
   # (Europe/Vilnius)
   # (Europe/Zaporozhye)
 +FET 10800# Further-eastern European Time
 + # (Europe/Minsk)
  MEST 7200 D  # Middle Europe Summer Time (not in zic)
  MET  3600# Middle Europe Time (not in zic)
  METDST   7200 D  # Middle Europe Summer Time (not in zic)
 diff --git a/src/timezone/tznames/Europe.txt 
 b/src/timezone/tznames/Europe.txt
 index 88abecca..6c35ab1 100644
 --- a/src/timezone/tznames/Europe.txt
 +++ b/src/timezone/tznames/Europe.txt
 @@ -154,6 +154,8 @@ EETDST  10800 D  # East-Egypt Summertime
   # (Europe/Uzhgorod)
   # (Europe/Vilnius)
   # (Europe/Zaporozhye)
 +FET 10800# Further-eastern European Time
 + # (Europe/Minsk)
  GMT 0# Greenwich Mean Time
   # (Africa/Abidjan)
   # (Africa/Bamako)
 

 -- 
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers
 
 



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-06 Thread Bruce Momjian
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
 
 Please take a second look at the diffs, they do *NOT* change the files
 in the timezone database, they change the Default set ot timezones that
 PostgreSQL uses.
 
 These files are maintained by PostgreSQL, there is even a README with an
 explicit mention that changes should be reported to pgsql-hackers
 

Oops, I see what you mean now.  I thought everything under src/timezone
was copied from others, but obviously I was wrong.

---

 
 
  
  ---
  
  On Sat, Oct  6, 2012 at 11:18:43AM +0200, Marc Balmer wrote:
  The attached patch would add the FET timezone abbreviation to the
  Default list _and_ the list of european abbreviations.
 
  - mb
  
  diff --git a/src/timezone/tznames/Default b/src/timezone/tznames/Default
  index 1369f47..7223ce5 100644
  --- a/src/timezone/tznames/Default
  +++ b/src/timezone/tznames/Default
  @@ -615,6 +615,8 @@ EETDST  10800 D  # East-Egypt Summertime
# (Europe/Uzhgorod)
# (Europe/Vilnius)
# (Europe/Zaporozhye)
  +FET 10800# Further-eastern European Time
  + # (Europe/Minsk)
   MEST 7200 D  # Middle Europe Summer Time (not in zic)
   MET  3600# Middle Europe Time (not in zic)
   METDST   7200 D  # Middle Europe Summer Time (not in zic)
  diff --git a/src/timezone/tznames/Europe.txt 
  b/src/timezone/tznames/Europe.txt
  index 88abecca..6c35ab1 100644
  --- a/src/timezone/tznames/Europe.txt
  +++ b/src/timezone/tznames/Europe.txt
  @@ -154,6 +154,8 @@ EETDST  10800 D  # East-Egypt Summertime
# (Europe/Uzhgorod)
# (Europe/Vilnius)
# (Europe/Zaporozhye)
  +FET 10800# Further-eastern European Time
  + # (Europe/Minsk)
   GMT 0# Greenwich Mean Time
# (Africa/Abidjan)
# (Africa/Bamako)
  
 
  -- 
  Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
  To make changes to your subscription:
  http://www.postgresql.org/mailpref/pgsql-hackers
  
  
 

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-06 Thread Tom Lane
Marc Balmer m...@msys.ch 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 thrilled
with making one-off changes on a first-to-complain basis.

I have no particular objection to adding FET, since it doesn't seem to
have any conflicts with other zone abbreviations; but we're really way
overdue for another global look at the abbreviation lists.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Add FET to Default and Europe.txt

2012-10-06 Thread Tom Lane
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 several issues that we need to deal with,
I think.

The biggest issue is that all of Russia has apparently (1) abandoned
daylight-savings time changes, and (2) settled on new standard time
zones that match up with their old DST times!  For example we've got

*** Zone Europe/Moscow   2:30:20 -  LMT 1880
*** 1951,1967 
 2:00   -   EET 1930 Jun 21
 3:00   Russia  MSK/MSD 1991 Mar 31 2:00s
 2:00   Russia  EE%sT   1992 Jan 19 2:00s
!3:00   Russia  MSK/MSD
  #
  # From Oscar van Vlijmen (2001-08-25): [This region consists of]
  # Samarskaya oblast', Udmyrtskaya respublika
  Zone Europe/Samara 3:20:36 -  LMT 1919 Jul  1 2:00
!3:00   -   KUYT1930 Jun 21 # Kuybyshev
!4:00   Russia  KUY%sT  1989 Mar 26 2:00s
 3:00   Russia  KUY%sT  1991 Mar 31 2:00s
 2:00   Russia  KUY%sT  1991 Sep 29 2:00s
 3:00   -   KUYT1991 Oct 20 3:00
!4:00   Russia  SAM%sT  # Samara Time
  #
  # From Oscar van Vlijmen (2001-08-25): [This region consists of]
  # Respublika Bashkortostan, Komi-Permyatskij avtonomnyj okrug,
--- 2120,2155 
 2:00   -   EET 1930 Jun 21
 3:00   Russia  MSK/MSD 1991 Mar 31 2:00s
 2:00   Russia  EE%sT   1992 Jan 19 2:00s
!3:00   Russia  MSK/MSD 2011 Mar 27 2:00s
!4:00   -   MSK
! #
! # Astrakhanskaya oblast', Kirovskaya oblast', Saratovskaya oblast',
! # Volgogradskaya oblast'.  Shanks  Pottenger say Kirov is still at +0400
! # but Wikipedia (2006-05-09) says +0300.  Perhaps it switched after the
! # others?  But we have no data.
! Zone Europe/Volgograd  2:57:40 -  LMT 1920 Jan  3
!3:00   -   TSAT1925 Apr  6 # Tsaritsyn Time
!3:00   -   STAT1930 Jun 21 # Stalingrad Time
!4:00   -   STAT1961 Nov 11
!4:00   Russia  VOL%sT  1989 Mar 26 2:00s # Volgograd T
!3:00   Russia  VOL%sT  1991 Mar 31 2:00s
!4:00   -   VOLT1992 Mar 29 2:00s
!3:00   Russia  VOL%sT  2011 Mar 27 2:00s
!4:00   -   VOLT
  #
  # From Oscar van Vlijmen (2001-08-25): [This region consists of]
  # Samarskaya oblast', Udmyrtskaya respublika
  Zone Europe/Samara 3:20:36 -  LMT 1919 Jul  1 2:00
!3:00   -   SAMT1930 Jun 21
!4:00   -   SAMT1935 Jan 27
!4:00   Russia  KUY%sT  1989 Mar 26 2:00s # Kuybyshev
 3:00   Russia  KUY%sT  1991 Mar 31 2:00s
 2:00   Russia  KUY%sT  1991 Sep 29 2:00s
 3:00   -   KUYT1991 Oct 20 3:00
!4:00   Russia  SAM%sT  2010 Mar 28 2:00s # Samara Time
!3:00   Russia  SAM%sT  2011 Mar 27 2:00s
!4:00   -   SAMT
! 
  #
  # From Oscar van Vlijmen (2001-08-25): [This region consists of]
  # Respublika Bashkortostan, Komi-Permyatskij avtonomnyj okrug,

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.

Lesser issues:

* The FET changes you noted, which seem to be related to the whole
Russian change.

* Mongolia seems to have moved an hour east too, but they kept summer
time:

*** 1268,1278 
  Zone  Asia/Choibalsan 7:38:00 -   LMT 1905 Aug
7:00-   ULAT1978
8:00-   ULAT1983 Apr
!   9:00Mongol  CHO%sT  # Choibalsan Time
  
  # Nepal
  # ZoneNAMEGMTOFF  RULES   FORMAT  [UNTIL]
--- 1783,1794 
  Zone  Asia/Choibalsan 7:38:00 -   LMT 1905 Aug
7:00-   ULAT1978
8:00-   ULAT1983 Apr
!   9:00Mongol  CHO%sT  2008 Mar 31 # Choibalsan Time
!   8:00Mongol  CHO%sT
  
  # Nepal
  # ZoneNAMEGMTOFF  RULES   FORMAT  [UNTIL]

* MAWT (Antarctica/Mawson) now means GMT+5 not GMT+6, and
Antarctica/Macquarie has adopted its very own zone name MIST.  It looks
from the Olson database as though all of the Australian Antarctic
stations have changed