@@ -11006,6 +11006,8 @@ SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'Asia/Tokyo' AT TIME ZONE 'A
1100611006<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 05:38:40</computeroutput>
1100711007SELECT TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-05' AT LOCAL;
1100811008<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>
1100911011SELECT TIME WITH TIME ZONE '20:38:40-05' AT LOCAL;
1101011012<lineannotation>Result: </lineannotation><computeroutput>17:38:40</computeroutput>
1101111013</screen>
@@ -11018,11 +11020,14 @@ SELECT TIME WITH TIME ZONE '20:38:40-05' AT LOCAL;
1101811020 Tokyo time to Chicago time. The fourth example shifts the time stamp
1101911021 with time zone value to the time zone currently specified by the
1102011022 <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"/>.
1102211027 </para>
1102311028
1102411029 <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
1102611031 date associated with the input value, the conversion is made using the
1102711032 current date of the session. Therefore, this static example may show a wrong
1102811033 result depending on the time of the year it is viewed because
0 commit comments