<entry>4713 BC</entry>
        <entry>294276 AD</entry>
        <entry>1 microsecond</entry>
       </row>
       <row>
        <entry><type>timestamp [ (<replaceable>p</replaceable>) ] with time zone</type></entry>
        <entry>8 bytes</entry>
        <entry>both date and time, with time zone</entry>
        <entry>4713 BC</entry>
        <entry>294276 AD</entry>
        <entry>1 microsecond</entry>
       </row>
       <row>
        <entry><type>date</type></entry>
        <entry>4 bytes</entry>
        <entry>date (no time of day)</entry>
        <entry>4713 BC</entry>
        <entry>5874897 AD</entry>
        <entry>1 day</entry>
       </row>
       <row>
        <entry><type>time [ (<replaceable>p</replaceable>) ] [ without time zone ]</type></entry>
        <entry>8 bytes</entry>
        <entry>time of day (no date)</entry>
        <entry>00:00:00</entry>
        <entry>24:00:00</entry>
        <entry>1 microsecond</entry>
       </row>
       <row>
        <entry><type>time [ (<replaceable>p</replaceable>) ] with time zone</type></entry>
        <entry>12 bytes</entry>
        <entry>time of day (no date), with time zone</entry>
        <!-- see MAX_TZDISP_HOUR in datatype/timestamp.h -->
        <entry>00:00:00+1559</entry>
        <entry>24:00:00-1559</entry>
        <entry>1 microsecond</entry>
       </row>
       <row>
        <entry><type>interval [ <replaceable>fields</replaceable> ] [ (<replaceable>p</replaceable>) ]</type></entry>
        <entry>16 bytes</entry>
        <entry>time interval</entry>
        <entry>-178000000 years</entry>
        <entry>178000000 years</entry>
        <entry>1 microsecond</entry>
       </row>
      </tbody>
     </tgroup>
    </table>

   <note>
    <para>
     The SQL standard requires that writing just <type>timestamp</type>
     be equivalent to <type>timestamp without time
     zone</type>, and <productname>PostgreSQL</productname> honors that
     behavior.  <type>timestamptz</type> is accepted as an
     abbreviation for <type>timestamp with time zone</type>; this is a
     <productname>PostgreSQL</productname> extension.
    </para>
   </note>

   <para>
    <type>time</type>, <type>timestamp</type>, and
    <type>interval</type> accept an optional precision value
    <replaceable>p</replaceable> which specifies the number of
    fractional digits retained in the seconds field. By default, there
    is no explicit bound on precision.  The allowed range of
    <replaceable>p</replaceable> is from 0 to 6.
   </para>

   <para>
    The <type>interval</type> type has an additional option, which is
    to restrict the set of stored fields by writing one of these phrases:
<literallayout class="monospaced">
YEAR
MONTH
DAY
HOUR
MINUTE
SECOND
YEAR TO MONTH
DAY TO HOUR
DAY TO MINUTE
DAY TO SECOND
HOUR TO MINUTE
HOUR TO SECOND
MINUTE TO SECOND
</literallayout>
    Note that if both <replaceable>fields</replaceable> and
    <replaceable>p</replaceable> are specified, the
    <replaceable>fields</replaceable> must include <literal>SECOND</literal>,
    since the precision applies only to the seconds.
   </para>

   <para>
    The type <type>time with time zone</type> is defined by the SQL
    standard, but the definition exhibits properties which lead to
    questionable usefulness. In most cases, a combination of
    <type>date</type>, <type>time</type>, <type>timestamp without time
    zone</type>, and <type>timestamp with time zone</type> should
    provide a complete range of date/time functionality required by
    any application.
   </para>

   <sect2 id="datatype-datetime-input">
    <title>Date/Time Input</title>

    <para>
     Date and time input is accepted in almost any reasonable format, including
     ISO 8601, <acronym>SQL</acronym>-compatible,
     traditional <productname>POSTGRES</productname>, and others.
     For some formats, ordering of day, month, and year in date input is
     ambiguous and there is support for specifying the expected
     ordering of these