11<!--
2- $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.77 2001/11/28 20:49:09 petere Exp $
2+ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.78 2001/12/08 03:24:22 thomas Exp $
33-->
44
55 <chapter id="datatype">
@@ -219,25 +219,25 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.77 2001/11/28 20:49:09 pe
219219 </row>
220220
221221 <row>
222- <entry><type>time [ without time zone ]</type></entry>
222+ <entry><type>time [(<replaceable>p</replaceable>) ] [ without time zone ]</type></entry>
223223 <entry></entry>
224224 <entry>time of day</entry>
225225 </row>
226226
227227 <row>
228- <entry><type>time with time zone</type></entry>
228+ <entry><type>time[ (<replaceable>p</replaceable>) ] with time zone</type></entry>
229229 <entry><type>timetz</type></entry>
230230 <entry>time of day, including time zone</entry>
231231 </row>
232232
233233 <row>
234- <entry><type>timestamp without time zone</type></entry>
234+ <entry><type>timestamp[ (<replaceable>p</replaceable>) ] without time zone</type></entry>
235235 <entry><type>timestamp</type></entry>
236236 <entry>date and time</entry>
237237 </row>
238238
239239 <row>
240- <entry><type>timestamp [ with time zone ]</type></entry>
240+ <entry><type>timestamp [(<replaceable>p</replaceable>) ] [ with time zone ]</type></entry>
241241 <entry><type>timestamptz</type></entry>
242242 <entry>date and time, including time zone</entry>
243243 </row>
@@ -1274,15 +1274,15 @@ SELECT b, char_length(b) FROM test2;
12741274 </thead>
12751275 <tbody>
12761276 <row>
1277- <entry><type>timestamp without time zone</type></entry>
1277+ <entry><type>timestamp[ (<replaceable>p</replaceable>) ] without time zone</type></entry>
12781278 <entry>both date and time</entry>
12791279 <entry>8 bytes</entry>
12801280 <entry>4713 BC</entry>
12811281 <entry>AD 1465001</entry>
12821282 <entry>1 microsecond / 14 digits</entry>
12831283 </row>
12841284 <row>
1285- <entry><type>timestamp [ with time zone ]</type></entry>
1285+ <entry><type>timestamp [(<replaceable>p</replaceable>) ] [ with time zone ]</type></entry>
12861286 <entry>both date and time</entry>
12871287 <entry>8 bytes</entry>
12881288 <entry>4713 BC</entry>
@@ -1324,28 +1324,38 @@ SELECT b, char_length(b) FROM test2;
13241324 </tbody>
13251325 </tgroup>
13261326 </table>
1327+ </para>
13271328
1328- <note>
1329- <para>
1330- Time zones, and time-zone conventions, are influenced by
1331- political conventions, not just physical effects. Time zones have
1332- become somewhat standardized during the 1900's, but continue to
1333- be prone to arbitrary changes with time.
1334- <productname>PostgreSQL</productname> uses your operating
1335- system's underlying features to provide time-zone
1336- support, and these systems usually contain information for only
1337- the time period 1902 through 2038 (corresponding to the full
1338- range of conventional Unix system time).
1339- <type>timestamp with time zone</type> will use time zone
1340- information only within that year range, and assumes that times
1341- are in UTC outside that range.
1342- </para>
1343- </note>
1329+ <para>
1330+ <type>time</type> and <type>timestamp</type> both accept an
1331+ option precision field <replaceable>p</replaceable> which
1332+ determines the number of digits retained beyond the seconds
1333+ decimal point. By default, there is no explicit bound on precision
1334+ and the actual precision is determined by the underlying double
1335+ precision floating point number used to store values in seconds
1336+ for <type>interval</type> and
1337+ since 2000-01-01 in the case of <type>timestamp</type>.
1338+ </para>
1339+
1340+ <para>
1341+ Time zones, and time-zone conventions, are influenced by
1342+ political decisions, not just physical effects. Time zones have
1343+ become somewhat standardized around the world during the 1900's,
1344+ but continue to
1345+ be prone to arbitrary changes.
1346+ <productname>PostgreSQL</productname> uses your operating
1347+ system's underlying features to provide time-zone
1348+ support, and these systems usually contain information for only
1349+ the time period 1902 through 2038 (corresponding to the full
1350+ range of conventional Unix system time).
1351+ <type>timestamp with time zone</type> will use time zone
1352+ information only within that year range, and assumes that times
1353+ are in UTC outside that range.
13441354 </para>
13451355
13461356 <para>
13471357 To ensure compatibility to earlier versions of <productname>PostgreSQL</productname>
1348- wealso continue to provide <type>datetime</type>
1358+ we continue to provide <type>datetime</type>
13491359 (equivalent to <type>timestamp</type>) and
13501360 <type>timespan</type> (equivalent to <type>interval</type>),
13511361 however support for these is now restricted to having an
@@ -1384,11 +1394,16 @@ SELECT b, char_length(b) FROM test2;
13841394 Remember that any date or time input needs to be enclosed into
13851395 single quotes, like text strings. Refer to <xref
13861396 linkend="sql-syntax-constants-generic"> for more information.
1387- SQL requires the following syntax
1397+ <acronym>SQL9x</acronym> requires the following syntax
13881398<synopsis>
1389- <replaceable>type</replaceable> '<replaceable>value</replaceable>'
1399+ <replaceable>type</replaceable>[ (<replaceable>p</replaceable>) ] '<replaceable>value</replaceable>'
13901400</synopsis>
1391- but <productname>PostgreSQL</productname> is more flexible.
1401+ where <replaceable>p</replaceable> is an integer specifying the
1402+ number of fractional digits in the seconds field, and is allowed
1403+ for <type>time</type>, <type>timestamp</type>, and <type>interval</type> types.
1404+ <productname>PostgreSQL</productname> is more flexible in
1405+ handling date/time than the
1406+ <acronym>SQL</acronym> standard requires.
13921407 </para>
13931408
13941409 <sect3>
@@ -1569,7 +1584,7 @@ SELECT b, char_length(b) FROM test2;
15691584 </sect3>
15701585
15711586 <sect3>
1572- <title><type>time [ without time zone ]</type></title>
1587+ <title><type>time [( <replaceable>p</replaceable> ) ] [ without time zone ]</type></title>
15731588
15741589 <indexterm>
15751590 <primary>time</primary>
@@ -1581,8 +1596,10 @@ SELECT b, char_length(b) FROM test2;
15811596 </indexterm>
15821597
15831598 <para>
1584- Per SQL99, this type can be referenced as <type>time</type> and
1585- as <type>time without time zone</type>.
1599+ Per SQL99, this type can be specified as <type>time</type> or
1600+ as <type>time without time zone</type>. The optional precision
1601+ <replaceable>p</replaceable> should be between 0 and 13, and
1602+ defaults to the precision of the input time literal.
15861603 </para>
15871604
15881605 <para>
@@ -1641,7 +1658,7 @@ SELECT b, char_length(b) FROM test2;
16411658 </sect3>
16421659
16431660 <sect3>
1644- <title><type>time with time zone</type></title>
1661+ <title><type>time[ ( <replaceable>precision</replaceable> ) ] with time zone</type></title>
16451662
16461663 <indexterm>
16471664 <primary>time with time zone</primary>
@@ -1662,6 +1679,12 @@ SELECT b, char_length(b) FROM test2;
16621679 required by any application.
16631680 </para>
16641681
1682+ <para>
1683+ The optional precision
1684+ <replaceable>p</replaceable> should be between 0 and 13, and
1685+ defaults to the precision of the input time literal.
1686+ </para>
1687+
16651688 <para>
16661689 <type>time with time zone</type> accepts all input also legal
16671690 for the <type>time</type> type, appended with a legal time zone,
@@ -1705,15 +1728,15 @@ SELECT b, char_length(b) FROM test2;
17051728 </sect3>
17061729
17071730 <sect3>
1708- <title><type>timestamp without time zone</type></title>
1731+ <title><type>timestamp[ (<replaceable>precision</replaceable>) ] without time zone</type></title>
17091732
17101733 <indexterm>
17111734 <primary>timestamp without time zone</primary>
17121735 <secondary>data type</secondary>
17131736 </indexterm>
17141737
17151738 <para>
1716- Valid input for the <type>timestamp without time zone</type>
1739+ Valid input for the <type>timestamp[ (<replaceable>p</replaceable>) ] without time zone</type>
17171740 type consists of a concatenation
17181741 of a date and a time, followed by an optional <literal>AD</literal> or
17191742 <literal>BC</literal>, followed by an optional time zone. (See below.)
@@ -1733,6 +1756,12 @@ January 8 04:05:06 1999 PST
17331756 is supported.
17341757 </para>
17351758
1759+ <para>
1760+ The optional precision
1761+ <replaceable>p</replaceable> should be between 0 and 13, and
1762+ defaults to the precision of the input <type>timestamp</type> literal.
1763+ </para>
1764+
17361765 <para>
17371766 For <type>timestamp without time zone</type>, any explicit time
17381767 zone specified in the input is silently swallowed. That is, the
@@ -1742,7 +1771,7 @@ January 8 04:05:06 1999 PST
17421771 </sect3>
17431772
17441773 <sect3>
1745- <title><type>timestamp with time zone</type></title>
1774+ <title><type>timestamp[ (<replaceable>precision</replaceable>) ] with time zone</type></title>
17461775
17471776 <indexterm>
17481777 <primary>timestamp</primary>
@@ -1768,6 +1797,12 @@ January 8 04:05:06 1999 PST
17681797 is supported.
17691798 </para>
17701799
1800+ <para>
1801+ The optional precision
1802+ <replaceable>p</replaceable> should be between 0 and 13, and
1803+ defaults to the precision of the input <type>timestamp</type> literal.
1804+ </para>
1805+
17711806 <para>
17721807 <table tocentry="1" id="datatype-timezone-table">
17731808 <title>Time Zone Input</title>
@@ -1852,7 +1887,9 @@ January 8 04:05:06 1999 PST
18521887 The following <acronym>SQL</acronym>-compatible functions can be
18531888 used as date or time
18541889 input for the corresponding data type: <literal>CURRENT_DATE</literal>,
1855- <literal>CURRENT_TIME</literal>, <literal>CURRENT_TIMESTAMP</literal>.
1890+ <literal>CURRENT_TIME</literal>,
1891+ <literal>CURRENT_TIMESTAMP</literal>. The latter two accept an
1892+ optional precision specification.
18561893 </para>
18571894
18581895 <para>