linkend="guc-log-timezone"/> to a time
        zone abbreviation, but you can use abbreviations in
        date/time input values and with the <literal>AT TIME ZONE</literal>
        operator.
       </para>
      </listitem>
      <listitem>
       <para>
        In addition to the timezone names and abbreviations,
        <productname>PostgreSQL</productname> will accept POSIX-style time zone
        specifications, as described in
        <xref linkend="datetime-posix-timezone-specs"/>.  This option is not
        normally preferable to using a named time zone, but it may be
        necessary if no suitable IANA time zone entry is available.
       </para>
      </listitem>
     </itemizedlist>

     In short, this is the difference between abbreviations
     and full names: abbreviations represent a specific offset from UTC,
     whereas many of the full names imply a local daylight-savings time
     rule, and so have two possible UTC offsets.  As an example,
     <literal>2014-06-04 12:00 America/New_York</literal> represents noon local
     time in New York, which for this particular date was Eastern Daylight
     Time (UTC-4).  So <literal>2014-06-04 12:00 EDT</literal> specifies that
     same time instant.  But <literal>2014-06-04 12:00 EST</literal> specifies
     noon Eastern Standard Time (UTC-5), regardless of whether daylight
     savings was nominally in effect on that date.
    </para>

    <note>
     <para>
      The sign in POSIX-style time zone specifications has the opposite meaning
      of the sign in ISO-8601 datetime values.  For example, the POSIX time zone
      for <literal>2014-06-04 12:00+04</literal> would be UTC-4.
     </para>
    </note>

    <para>
     To complicate matters, some jurisdictions have used the same timezone
     abbreviation to mean different UTC offsets at different times; for
     example, in Moscow <literal>MSK</literal> has meant UTC+3 in some years and
     UTC+4 in others.  <productname>PostgreSQL</productname> interprets such
     abbreviations according to whatever they meant (or had most recently
     meant) on the specified date; but, as with the <literal>EST</literal> example
     above, this is not necessarily the same as local civil time on that date.
    </para>

    <para>
     In all cases, timezone names and abbreviations are recognized
     case-insensitively.  (This is a change from <productname>PostgreSQL</productname>
     versions prior to 8.2, which were case-sensitive in some contexts but
     not others.)
    </para>

    <para>
     Neither timezone names nor abbreviations are hard-wired into the server;
     they are obtained from configuration files stored under
     <filename>.../share/timezone/</filename> and <filename>.../share/timezonesets/</filename>
     of the installation directory
     (see <xref linkend="datetime-config-files"/>).
    </para>

    <para>
     The <xref linkend="guc-timezone"/> configuration parameter can
     be set in the file <filename>postgresql.conf</filename>, or in any of the
     other standard ways described in <xref linkend="runtime-config"/>.
     There are also some special ways to set it:

     <itemizedlist>
      <listitem>
       <para>
        The <acronym>SQL</acronym> command <command>SET TIME ZONE</command>
        sets the time zone for the session.  This is an alternative spelling
        of <command>SET TIMEZONE TO</command> with a more SQL-spec-compatible syntax.
       </para>
      </listitem>

      <listitem>
       <para>
        The <envar>PGTZ</envar> environment variable is used by
        <application>libpq</application> clients
        to send a <command>SET TIME ZONE</command>
        command to the server upon connection.
       </para>
      </listitem>
     </itemizedlist>
    </para>
   </sect2>

   <sect2 id="datatype-interval-input">
    <title>Interval Input</title>

    <indexterm>
     <primary>interval</primary>
    </indexterm>

     <para>
      <type>interval</type> values can