<literal>at</literal>, <literal>on</literal>).
       </para>
      </step>

      <step>
       <para>
        If still not found, throw an error.
       </para>
      </step>
     </substeps>
    </step>

    <step>
     <para>
      When the token is a number or number field:
     </para>

     <substeps>
      <step>
       <para>
        If there are eight or six digits,
        and if no other date fields have been previously read, then interpret
        as a <quote>concatenated date</quote> (e.g.,
        <literal>19990118</literal> or <literal>990118</literal>).
        The interpretation is <literal>YYYYMMDD</literal> or <literal>YYMMDD</literal>.
       </para>
      </step>

      <step>
       <para>
        If the token is three digits
        and a year has already been read, then interpret as day of year.
       </para>
      </step>

      <step>
       <para>
        If four or six digits and a year has already been read, then
        interpret as a time (<literal>HHMM</literal> or <literal>HHMMSS</literal>).
       </para>
      </step>

      <step>
       <para>
        If three or more digits and no date fields have yet been found,
        interpret as a year (this forces yy-mm-dd ordering of the remaining
        date fields).
       </para>
      </step>

      <step>
       <para>
        Otherwise the date field ordering is assumed to follow the
        <varname>DateStyle</varname> setting: mm-dd-yy, dd-mm-yy, or yy-mm-dd.
        Throw an error if a month or day field is found to be out of range.
       </para>
      </step>
     </substeps>
    </step>

    <step>
     <para>
      If BC has been specified, negate the year and add one for
      internal storage.  (There is no year zero in the Gregorian
      calendar, so numerically 1 BC becomes year zero.)
     </para>
    </step>

    <step>
     <para>
      If BC was not specified, and if the year field was two digits in length,
      then adjust the year to four digits. If the field is less than 70, then
      add 2000, otherwise add 1900.

      <tip>
       <para>
        Gregorian years AD 1&ndash;99 can be entered by using 4 digits with leading
        zeros (e.g., <literal>0099</literal> is AD 99).
       </para>
      </tip>
     </para>
    </step>
   </procedure>
  </sect1>


  <sect1 id="datetime-invalid-input">
   <title>Handling of Invalid or Ambiguous Timestamps</title>

   <para>
    Ordinarily, if a date/time string is syntactically valid but contains
    out-of-range field values, an error will be thrown.  For example, input
    specifying the 31st of February will be rejected.
   </para>

   <para>
    During a daylight-savings-time transition, it is possible for a
    seemingly valid timestamp string to represent a nonexistent or ambiguous
    timestamp.  Such cases are not rejected; the ambiguity is resolved by
    determining which UTC offset to apply.  For example, supposing that the
    <xref linkend="guc-timezone"/> parameter is set
    to <literal>America/New_York</literal>, consider
<programlisting>
=&gt; SELECT '2018-03-11 02:30'::timestamptz;
      timestamptz
------------------------
 2018-03-11 03:30:00-04
(1 row)
</programlisting>
    Because that day was a spring-forward transition date in that time zone,
    there was no civil time instant 2:30AM; clocks jumped forward from 2AM
    EST to 3AM EDT.  <productname>PostgreSQL</productname> interprets the
    given time as if it were standard time (UTC-5), which then renders as
    3:30AM EDT (UTC-4).
   </para>

   <para>
    Conversely, consider the behavior during a fall-back transition:
<programlisting>
=&gt; SELECT '2018-11-04 01:30'::timestamptz;
      timestamptz
------------------------
 2018-11-04 01:30:00-05
(1 row)
</programlisting>
    On that date, there were two possible interpretations of 1:30AM; there
    was 1:30AM EDT, and then an hour later after clocks jumped back from
    2AM EDT to 1AM EST, there was 1:30AM EST.
    Again, <productname>PostgreSQL</productname>