<para>

Conversely, consider the behavior during a fall-back transition:

<programlisting>

=&gt; SELECT '2018-11-0402:30'::timestamptz;

=&gt; SELECT '2018-11-0401:30'::timestamptz;

timestamptz

------------------------

2018-11-0402:30:00-05

2018-11-0401:30:00-05

(1 row)

</programlisting>

On that date, there were two possible interpretations of2:30AM; there

was2:30AM EDT, and then an hour later afterthe reversion to standard

time, there was2:30AM EST.

On that date, there were two possible interpretations of1:30AM; there

was1:30AM EDT, and then an hour later afterclocks jumped back from

2AM EDT to 1AM EST, there was1:30AM EST.

Again, <productname>PostgreSQL</productname> interprets the given time

as if it were standard time (UTC-5). We can force thematter by

specifying daylight-savings time:

as if it were standard time (UTC-5). We can force theother

interpretation byspecifying daylight-savings time:

<programlisting>

=&gt; SELECT '2018-11-0402:30 EDT'::timestamptz;

=&gt; SELECT '2018-11-0401:30 EDT'::timestamptz;

timestamptz

------------------------

2018-11-04 01:30:00-05

2018-11-04 01:30:00-04

(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.

</para>

<para>