|
|
|
|
@ -1,5 +1,5 @@ |
|
|
|
|
<!-- |
|
|
|
|
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.162 2005/10/15 01:47:11 neilc Exp $ |
|
|
|
|
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.163 2005/10/22 19:33:57 tgl Exp $ |
|
|
|
|
--> |
|
|
|
|
|
|
|
|
|
<chapter id="datatype"> |
|
|
|
|
@ -1367,7 +1367,7 @@ SELECT b, char_length(b) FROM test2; |
|
|
|
|
<entry><type>time [ (<replaceable>p</replaceable>) ] [ without time zone ]</type></entry> |
|
|
|
|
<entry>8 bytes</entry> |
|
|
|
|
<entry>times of day only</entry> |
|
|
|
|
<entry>00:00:00.00</entry> |
|
|
|
|
<entry>00:00:00</entry> |
|
|
|
|
<entry>24:00:00</entry> |
|
|
|
|
<entry>1 microsecond / 14 digits</entry> |
|
|
|
|
</row> |
|
|
|
|
@ -1375,8 +1375,8 @@ SELECT b, char_length(b) FROM test2; |
|
|
|
|
<entry><type>time [ (<replaceable>p</replaceable>) ] with time zone</type></entry> |
|
|
|
|
<entry>12 bytes</entry> |
|
|
|
|
<entry>times of day only, with time zone</entry> |
|
|
|
|
<entry>00:00:00.00+12</entry> |
|
|
|
|
<entry>24:00:00-12</entry> |
|
|
|
|
<entry>00:00:00+1359</entry> |
|
|
|
|
<entry>24:00:00-1359</entry> |
|
|
|
|
<entry>1 microsecond / 14 digits</entry> |
|
|
|
|
</row> |
|
|
|
|
</tbody> |
|
|
|
|
@ -1759,19 +1759,22 @@ January 8 04:05:06 1999 PST |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
The <acronym>SQL</acronym> standard differentiates <type>timestamp without time zone</type> |
|
|
|
|
and <type>timestamp with time zone</type> literals by the existence of a |
|
|
|
|
<quote>+</quote>; or <quote>-</quote>. Hence, according to the standard, |
|
|
|
|
and <type>timestamp with time zone</type> literals by the presence of a |
|
|
|
|
<quote>+</quote> or <quote>-</quote>. 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> |
|
|
|
|
differs from the standard by requiring that <type>timestamp with time zone</type> |
|
|
|
|
literals be explicitly typed: |
|
|
|
|
<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> |
|
|
|
|
If a literal is not explicitly indicated as being of <type>timestamp with time zone</type>, |
|
|
|
|
<productname>PostgreSQL</productname> will silently ignore any time zone indication in the literal. |
|
|
|
|
That is, the resulting date/time value is derived from the date/time |
|
|
|
|
In a literal that has been decided 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 value, and is not adjusted for time zone. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|