|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.178 2006/10/17 21:03:20 tgl Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.179 2006/10/18 16:43:13 tgl Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="datatype">
|
4 | 4 | <title id="datatype-title">Data Types</title>
|
@@ -1356,8 +1356,8 @@ SELECT b, char_length(b) FROM test2;
|
1356 | 1356 | <entry><type>time [ (<replaceable>p</replaceable>) ] with time zone</type></entry>
|
1357 | 1357 | <entry>12 bytes</entry>
|
1358 | 1358 | <entry>times of day only, with time zone</entry>
|
1359 |
| - <entry>00:00:00+1359</entry> |
1360 |
| - <entry>24:00:00-1359</entry> |
| 1359 | + <entry>00:00:00+1459</entry> |
| 1360 | + <entry>24:00:00-1459</entry> |
1361 | 1361 | <entry>1 microsecond / 14 digits</entry>
|
1362 | 1362 | </row>
|
1363 | 1363 | </tbody>
|
@@ -1594,7 +1594,8 @@ SELECT b, char_length(b) FROM test2;
|
1594 | 1594 | and <xref linkend="datatype-timezone-table">.) If a time zone is
|
1595 | 1595 | specified in the input for <type>time without time zone</type>,
|
1596 | 1596 | it is silently ignored. You can also specify a date but it will
|
1597 |
| - be ignored, except when you use a full time zone name like |
| 1597 | + be ignored, except when you use a time zone name that involves a |
| 1598 | + daylight-savings rule, such as |
1598 | 1599 | <literal>America/New_York</literal>. In this case specifying the date
|
1599 | 1600 | is required in order to determine whether standard or daylight-savings
|
1600 | 1601 | time applies. The appropriate time zone offset is recorded in the
|
@@ -1747,12 +1748,7 @@ SELECT b, char_length(b) FROM test2;
|
1747 | 1748 | </programlisting>
|
1748 | 1749 |
|
1749 | 1750 | are valid values, which follow the <acronym>ISO</acronym> 8601
|
1750 |
| - standard. You can also specify the full time zone name as in |
1751 |
| -<programlisting> |
1752 |
| -1999-01-08 04:05:06 America/New_York |
1753 |
| -</programlisting> |
1754 |
| - |
1755 |
| - In addition, the wide-spread format |
| 1751 | + standard. In addition, the wide-spread format |
1756 | 1752 | <programlisting>
|
1757 | 1753 | January 8 04:05:06 1999 PST
|
1758 | 1754 | </programlisting>
|
@@ -2210,12 +2206,7 @@ January 8 04:05:06 1999 PST
|
2210 | 2206 | There is a conceptual and practical difference between the abbreviations
|
2211 | 2207 | and the full names: abbreviations always represent a fixed offset from
|
2212 | 2208 | UTC, whereas most of the full names imply a local daylight-savings time
|
2213 |
| - rule and so have two possible UTC offsets. That's why you always have to |
2214 |
| - specify a date if you want to use full time zone names in <type>timetz</> |
2215 |
| - values. This is also the reason why you should set <xref |
2216 |
| - linkend="guc-timezone"> to a full time zone name: this way, |
2217 |
| - <productname>PostgreSQL</productname> |
2218 |
| - will always know the correct UTC offset for your region. |
| 2209 | + rule and so have two possible UTC offsets. |
2219 | 2210 | </para>
|
2220 | 2211 |
|
2221 | 2212 | <para>
|
|
0 commit comments