Fix up some problems in handling of zic-style time zone names in datetime

input routines.  Remove the former "DecodePosixTimezone" function in favor of
letting the zic code handle POSIX-style zone specs (see tzparse()).  In
particular this means that "PST+3" now means the same as "-03", whereas it
used to mean "-11" --- the zone abbreviation is effectively just a noise word
in this syntax.  Make sure that all named and POSIX-style zone names will be
parsed as a single token.  Fix long-standing bogosities in printing and input
of fractional-hour timezone offsets (since the tzparse() code will accept
these, we'd better make 'em work).  Also correct an error in the original
coding of the zic-zone-name patch: in "timestamp without time zone" input,
zone names are supposed to be allowed but ignored, but the coding was such
that the zone changed the interpretation anyway.

Author: tglsfdc

doc/src/sgml/datatype.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.177 2006/10/16 19:58:26 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.178 2006/10/17 21:03:20 tgl Exp $ -->
 
  <chapter id="datatype">
   <title id="datatype-title">Data Types</title>
@@ -1675,12 +1675,16 @@ SELECT b, char_length(b) FROM test2;
         <tbody>
          <row>
           <entry><literal>PST</literal></entry>
-          <entry>Pacific Standard Time</entry>
+          <entry>Abbreviation (for Pacific Standard Time)</entry>
          </row>
          <row>
           <entry><literal>America/New_York</literal></entry>
           <entry>Full time zone name</entry>
          </row>
+         <row>
+          <entry><literal>PST8PDT</literal></entry>
+          <entry>POSIX-style time zone specification</entry>
+         </row>
          <row>
           <entry><literal>-8:00</literal></entry>
           <entry>ISO-8601 offset for PST</entry>
@@ -2183,7 +2187,7 @@ January 8 04:05:06 1999 PST
       <listitem>
        <para>
         In addition to the timezone names and abbreviations,
-        <productname>PostgreSQL</productname> will accept time zone
+        <productname>PostgreSQL</productname> will accept POSIX-style time zone
         specifications of the form <replaceable>STD</><replaceable>offset</> or
         <replaceable>STD</><replaceable>offset</><replaceable>DST</>, where
         <replaceable>STD</> is a zone abbreviation, <replaceable>offset</> is a
@@ -2220,12 +2224,6 @@ January 8 04:05:06 1999 PST
      prior to 8.2, which were case-sensitive in some contexts and not others.)
     </para>
 
-    <para>
-     Note that timezone names are <emphasis>not</> used for date/time output
-     &mdash; all supported output formats use numeric timezone displays to
-     avoid ambiguity.
-    </para>
-
     <para>
      Neither full names nor abbreviations are hard-wired into the server;
      they are obtained from configuration files stored under

doc/src/sgml/datetime.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.54 2006/09/22 16:35:55 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.55 2006/10/17 21:03:20 tgl Exp $ -->
 
  <appendix id="datetime-appendix">
   <title>Date/Time Support</title>
@@ -46,9 +46,9 @@
        <para>
         If the numeric token contains a dash (<literal>-</>), slash
         (<literal>/</>), or two or more dots (<literal>.</>), this is
-        a date string which may have a text month. In case of a slash
-        (<literal>/</>) it can also be a full time zone name like
-        <literal>America/New_York</>.
+        a date string which may have a text month.  If a date token has
+        already been seen, it is instead interpreted as a time zone
+        name (e.g., <literal>America/New_York</>).
        </para>
       </step>
 
@@ -64,7 +64,7 @@
       <step>
        <para>
         If the token starts with a plus (<literal>+</>) or minus
-        (<literal>-</>), then it is either a time zone or a special
+        (<literal>-</>), then it is either a numeric time zone or a special
         field.
        </para>
       </step>
@@ -73,30 +73,24 @@
 
     <step>
      <para>
-      If the token is a text string, match up with possible strings.
+      If the token is a text string, match up with possible strings:
      </para>
 
      <substeps>
       <step>
        <para>
-        Do a binary-search table lookup for the token
-        as either a special string (e.g., <literal>today</literal>),
-        day (e.g., <literal>Thursday</literal>),
-        month (e.g., <literal>January</literal>),
-        or noise word (e.g., <literal>at</literal>, <literal>on</literal>).
-       </para>
-
-       <para>
-        Set field values and bit mask for fields.
-        For example, set year, month, day for <literal>today</literal>,
-        and additionally hour, minute, second for <literal>now</literal>.
+        Do a binary-search table lookup for the token as a time zone
+        abbreviation.
        </para>
       </step>
 
       <step>
        <para>
         If not found, do a similar binary-search table lookup to match
-        the token with a time zone.
+        the token as either a special string (e.g., <literal>today</literal>),
+        day (e.g., <literal>Thursday</literal>),
+        month (e.g., <literal>January</literal>),
+        or noise word (e.g., <literal>at</literal>, <literal>on</literal>).
        </para>
       </step>