addition, the common format:
<programlisting>
January 8 04:05:06 1999 PST
</programlisting>
      is supported.
     </para>

     <para>
      The <acronym>SQL</acronym> standard differentiates
      <type>timestamp without time zone</type>
      and <type>timestamp with time zone</type> literals by the presence of a
      <quote>+</quote> or <quote>-</quote> symbol and time zone offset after
      the time.  Hence, according to the standard,

<programlisting>
TIMESTAMP '2004-10-19 10:23:54'
</programlisting>

      is a <type>timestamp without time zone</type>, while

<programlisting>
TIMESTAMP '2004-10-19 10:23:54+02'
</programlisting>

      is a <type>timestamp with time zone</type>.
      <productname>PostgreSQL</productname> never examines the content of a
      literal string before determining its type, and therefore will treat
      both of the above as <type>timestamp without time zone</type>.  To
      ensure that a literal is treated as <type>timestamp with time
      zone</type>, give it the correct explicit type:

<programlisting>
TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'
</programlisting>
     </para>

     <para>
      In a value that has been determined to be <type>timestamp without time
      zone</type>, <productname>PostgreSQL</productname> will silently ignore
      any time zone indication.
      That is, the resulting value is derived from the date/time
      fields in the input string, and is not adjusted for time zone.
     </para>

     <para>
      For <type>timestamp with time zone</type> values, an input string
      that includes an explicit time zone will be converted to UTC
      (<glossterm linkend="glossary-utc">Universal Coordinated
      Time</glossterm>) using the appropriate offset
      for that time zone.  If no time zone is stated in the input string,
      then it is assumed to be in the time zone indicated by the system's
      <xref linkend="guc-timezone"/> parameter, and is converted to UTC using the
      offset for the <varname>timezone</varname> zone.
      In either case, the value is stored internally as UTC, and the
      originally stated or assumed time zone is not retained.
     </para>

     <para>
      When a <type>timestamp with time
      zone</type> value is output, it is always converted from UTC to the
      current <varname>timezone</varname> zone, and displayed as local time in that
      zone.  To see the time in another time zone, either change
      <varname>timezone</varname> or use the <literal>AT TIME ZONE</literal> construct
      (see <xref linkend="functions-datetime-zoneconvert"/>).
     </para>

     <para>
      Conversions between <type>timestamp without time zone</type> and
      <type>timestamp with time zone</type> normally assume that the
      <type>timestamp without time zone</type> value should be taken or given
      as <varname>timezone</varname> local time.  A different time zone can
      be specified for the conversion using <literal>AT TIME ZONE</literal>.
     </para>
    </sect3>

    <sect3 id="datatype-datetime-special-values">
     <title>Special Values</title>

     <indexterm>
      <primary>time</primary>
      <secondary>constants</secondary>
     </indexterm>

     <indexterm>
      <primary>date</primary>
      <secondary>constants</secondary>
     </indexterm>

     <para>
      <productname>PostgreSQL</productname> supports several
      special date/time input values for convenience, as shown in <xref
      linkend="datatype-datetime-special-table"/>.  The values
      <literal>infinity</literal> and <literal>-infinity</literal>
      are specially represented inside the system and will be displayed
      unchanged; but the others are simply notational shorthands
      that will be converted to ordinary date/time values when read.
      (In particular, <literal>now</literal> and related strings are converted
      to a specific time value as soon as they are read.)
      All of these values need to be enclosed in single