@@ -11006,6 +11006,8 @@ SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'Asia/Tokyo' AT TIME ZONE 'A
11006
11006
<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 05:38:40</computeroutput>
11007
11007
SELECT TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-05' AT LOCAL;
11008
11008
<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 17:38:40</computeroutput>
11009
+ SELECT TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-05' AT TIME ZONE '+05';
11010
+ <lineannotation>Result: </lineannotation><computeroutput>2001-02-16 20:38:40</computeroutput>
11009
11011
SELECT TIME WITH TIME ZONE '20:38:40-05' AT LOCAL;
11010
11012
<lineannotation>Result: </lineannotation><computeroutput>17:38:40</computeroutput>
11011
11013
</screen>
@@ -11018,11 +11020,14 @@ SELECT TIME WITH TIME ZONE '20:38:40-05' AT LOCAL;
11018
11020
Tokyo time to Chicago time. The fourth example shifts the time stamp
11019
11021
with time zone value to the time zone currently specified by the
11020
11022
<varname>TimeZone</varname> setting and returns the value without a
11021
- time zone.
11023
+ time zone. The fifth example demonstrates that the sign in a POSIX-style
11024
+ time zone specification has the opposite meaning of the sign in an
11025
+ ISO-8601 datetime literal, as described in <xref linkend="datatype-timezones"/>
11026
+ and <xref linkend="datetime-appendix"/>.
11022
11027
</para>
11023
11028
11024
11029
<para>
11025
- The fifth example is a cautionary tale. Due to the fact that there is no
11030
+ The sixth example is a cautionary tale. Due to the fact that there is no
11026
11031
date associated with the input value, the conversion is made using the
11027
11032
current date of the session. Therefore, this static example may show a wrong
11028
11033
result depending on the time of the year it is viewed because
0 commit comments