<entry><replaceable>day</replaceable>/<replaceable>month</replaceable>/<replaceable>year</replaceable></entry>
         <entry><literal>Wed 17 Dec 07:37:16 1997 PST</literal></entry>
        </row>
       </tbody>
      </tgroup>
     </table>

    <para>
     In the <acronym>ISO</acronym> style, the time zone is always shown as
     a signed numeric offset from UTC, with positive sign used for zones
     east of Greenwich.  The offset will be shown
     as <replaceable>hh</replaceable> (hours only) if it is an integral
     number of hours, else
     as <replaceable>hh</replaceable>:<replaceable>mm</replaceable> if it
     is an integral number of minutes, else as
     <replaceable>hh</replaceable>:<replaceable>mm</replaceable>:<replaceable>ss</replaceable>.
     (The third case is not possible with any modern time zone standard,
     but it can appear when working with timestamps that predate the
     adoption of standardized time zones.)
     In the other date styles, the time zone is shown as an alphabetic
     abbreviation if one is in common use in the current zone.  Otherwise
     it appears as a signed numeric offset in ISO 8601 basic format
     (<replaceable>hh</replaceable> or <replaceable>hhmm</replaceable>).
     The alphabetic abbreviations shown in these styles are taken from the
     IANA time zone database entry currently selected by the
     <xref linkend="guc-timezone"/> run-time parameter; they are not
     affected by the <xref linkend="guc-timezone-abbreviations"/> setting.
    </para>

    <para>
     The date/time style can be selected by the user using the
     <command>SET datestyle</command> command, the <xref
     linkend="guc-datestyle"/> parameter in the
     <filename>postgresql.conf</filename> configuration file, or the
     <envar>PGDATESTYLE</envar> environment variable on the server or
     client.
    </para>

    <para>
     The formatting function <function>to_char</function>
     (see <xref linkend="functions-formatting"/>) is also available as
     a more flexible way to format date/time output.
    </para>
   </sect2>

   <sect2 id="datatype-timezones">
    <title>Time Zones</title>

    <indexterm zone="datatype-timezones">
     <primary>time zone</primary>
    </indexterm>

   <para>
    Time zones, and time-zone conventions, are influenced by
    political decisions, not just earth geometry. Time zones around the
    world became somewhat standardized during the 1900s,
    but continue to be prone to arbitrary changes, particularly with
    respect to daylight-savings rules.
    <productname>PostgreSQL</productname> uses the widely-used
    IANA (Olson) time zone database for information about
    historical time zone rules.  For times in the future, the assumption
    is that the latest known rules for a given time zone will
    continue to be observed indefinitely far into the future.
   </para>

    <para>
     <productname>PostgreSQL</productname> endeavors to be compatible with
     the <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