diff --git a/doc/src/sgml/datetime.sgml b/doc/src/sgml/datetime.sgml
index c53bd2f379f..adaf72dcbd5 100644
--- a/doc/src/sgml/datetime.sgml
+++ b/doc/src/sgml/datetime.sgml
@@ -210,27 +210,25 @@
    <para>
     Conversely, consider the behavior during a fall-back transition:
 <programlisting>
-=&gt; SELECT '2018-11-04 02:30'::timestamptz;
-      timestamptz
-------------------------
- 2018-11-04 02:30:00-05
-(1 row)
-</programlisting>
-    On that date, there were two possible interpretations of 2:30AM; there
-    was 2:30AM EDT, and then an hour later after the reversion to standard
-    time, there was 2:30AM EST.
-    Again, <productname>PostgreSQL</productname> interprets the given time
-    as if it were standard time (UTC-5).  We can force the matter by
-    specifying daylight-savings time:
-<programlisting>
-=&gt; SELECT '2018-11-04 02:30 EDT'::timestamptz;
+=&gt; SELECT '2018-11-04 01:30'::timestamptz;
       timestamptz
 ------------------------
  2018-11-04 01:30:00-05
 (1 row)
 </programlisting>
-    This timestamp could validly be rendered as either 2:30 UTC-4 or
-    1:30 UTC-5; the timestamp output code chooses the latter.
+    On that date, there were two possible interpretations of 1:30AM; there
+    was 1:30AM EDT, and then an hour later after clocks jumped back from
+    2AM EDT to 1AM EST, there was 1:30AM EST.
+    Again, <productname>PostgreSQL</productname> interprets the given time
+    as if it were standard time (UTC-5).  We can force the other
+    interpretation by specifying daylight-savings time:
+<programlisting>
+=&gt; SELECT '2018-11-04 01:30 EDT'::timestamptz;
+      timestamptz
+------------------------
+ 2018-11-04 01:30:00-04
+(1 row)
+</programlisting>
    </para>
 
    <para>