Include specific info on available timezones.

Document date/time input parsing procedure.

doc/src/sgml/datatype.sgml

@@ -520,10 +520,14 @@ This is set at compile time and may change in a future release.
    <title>Date/Time Types</title>
 
    <para>
-There are two fundamental kinds of date and time measurements:
+    There are two fundamental kinds of date and time measurements
+    provided by <productname>Postgres</productname>:
     absolute clock times and relative time intervals.
-Both kinds of quantities should have behaviors demonstrating both
+    Both kinds of time measurements should demonstrate both
     continuity and smoothness.
+   </para>
+
+   <para>
     <productname>Postgres</productname> supplies two primary user-oriented 
     date and time types,
     <type>datetime</type> and <type>timespan</type>, as well as 
@@ -677,10 +681,13 @@ for historical reasons.
     </table>
    </para>
 
+   <sect2>
+    <title>SQL92 Conventions</title>
+
     <para>
      <productname>Postgres</productname> endeavors to be compatible with
      <acronym>SQL92</acronym> definitions for typical usage.
-The <acronym>SQL92</acronym> standard has an odd mix of date and
+     However, the <acronym>SQL92</acronym> standard has an odd mix of date and
      time types and capabilities. Two obvious problems are:
 
      <itemizedlist>
@@ -688,16 +695,20 @@ time types and capabilities. Two obvious problems are:
        <para>
 	Although the <type>date</type> type 
 	does not have an associated time zone, the
-<type>time</type> type can or does.</para></listitem>
+	<type>time</type> type can or does.
+       </para>
+      </listitem>
 
       <listitem>
        <para>
 	The default time zone is specified as a constant integer offset 
-from GMT/UTC.</para></listitem>
+	from GMT/UTC.
+       </para>
+      </listitem>
 
      </itemizedlist>
 
-However, time zones in the real world can have no meaning unless 
+     Time zones in the real world can have no meaning unless 
      associated with a date as well as a time
      since the offset may vary through the year with daylight savings
      time boundaries.
@@ -724,6 +735,7 @@ being deprecated in favor of <type>timestamp</type> and <type>interval</type>.
      The more arcane features of the date/time definitions from 
      the <acronym>SQL92</acronym> standard are not likely to be pursued.
     </para>
+   </sect2>
 
 <sect2>
 <title>Date/Time Styles</title>
@@ -838,6 +850,23 @@ In future releases, the default may become "ISO" (compatible with ISO-8601),
 which alleviates date specification ambiguities and Y2K collation problems.
 </para>
 
+</sect2>
+
+   <sect2>
+    <title>Calendar</title>
+
+    <para>
+     <productname>Postgres</productname> uses Julian dates
+     for all date/time calculations. They have the nice property of correctly
+     predicting/calculating any date more recent than something like 4013BC
+     to far into the future, using the assumption that the length of the
+     year is 365.2425 days.
+    </para>
+
+    <para>
+     Date conventions before the 19th century make for interesting reading,
+     but are not consistant enough to warrant coding into a date/time handler.
+    </para>
    </sect2>
 
    <sect2>
@@ -845,11 +874,19 @@ which alleviates date specification ambiguities and Y2K collation problems.
 
     <para>
      <productname>Postgres</productname> obtains time zone support 
-from the underlying operating system.
-All dates and times are stored internally in Universal Coordinated Time (UTC),
+     from the underlying operating system for dates between 1902 and
+     2038 (near the typical date limits for Unix-style
+     systems). Outside of this range, all dates are assumed to be
+     specified and used in Universal Coordinated Time (UTC).
+    </para>
+
+    <para>
+     All dates and times are stored internally in Universal UTC,
      alternately known as Greenwich Mean Time (GMT). 
      Times are converted to local time on the database server before being
-sent to the client frontend, hence by default are in the server time zone.</para>
+     sent to the client frontend, hence by default are in the server
+     time zone.
+    </para>
 
     <para>
      There are several ways to affect the time zone behavior: