<acronym>SQL</acronym> standard definitions for typical usage.
     However, the <acronym>SQL</acronym> standard has an odd mix of date and
     time types and capabilities. Two obvious problems are:

     <itemizedlist>
      <listitem>
       <para>
        Although the <type>date</type> type
        cannot have an associated time zone, the
        <type>time</type> type can.
        Time zones in the real world have little meaning unless
        associated with a date as well as a time,
        since the offset can vary through the year with daylight-saving
        time boundaries.
       </para>
      </listitem>

      <listitem>
       <para>
        The default time zone is specified as a constant numeric offset
        from <acronym>UTC</acronym>. It is therefore impossible to adapt to
        daylight-saving time when doing date/time arithmetic across
        <acronym>DST</acronym> boundaries.
       </para>
      </listitem>

     </itemizedlist>
    </para>

    <para>
     To address these difficulties, we recommend using date/time types
     that contain both date and time when using time zones. We
     do <emphasis>not</emphasis> recommend using the type <type>time with
     time zone</type> (though it is supported by
     <productname>PostgreSQL</productname> for legacy applications and
     for compliance with the <acronym>SQL</acronym> standard).
     <productname>PostgreSQL</productname> assumes
     your local time zone for any type containing only date or time.
    </para>

    <para>
     All timezone-aware dates and times are stored internally in
     <acronym>UTC</acronym>.  They are converted to local time
     in the zone specified by the <xref linkend="guc-timezone"/> configuration
     parameter before being displayed to the client.
    </para>

    <para>
     <productname>PostgreSQL</productname> allows you to specify time zones in
     three different forms:
     <itemizedlist>
      <listitem>
       <para>
        A full time zone name, for example <literal>America/New_York</literal>.
        The recognized time zone names are listed in the
        <literal>pg_timezone_names</literal> view (see <xref
        linkend="view-pg-timezone-names"/>).
        <productname>PostgreSQL</productname> uses the widely-used IANA
        time zone data for this purpose, so the same time zone
        names are also recognized by other software.
       </para>
      </listitem>
      <listitem>
       <para>
        A time zone abbreviation, for example <literal>PST</literal>.  Such a
        specification merely defines a particular offset from UTC, in
        contrast to full time zone names which can imply a set of daylight
        savings transition rules as well.  The recognized abbreviations
        are listed in the <literal>pg_timezone_abbrevs</literal> view (see <xref
        linkend="view-pg-timezone-abbrevs"/>).  You cannot set the
        configuration parameters <xref linkend="guc-timezone"/> or
        <xref 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