diff options
| -rw-r--r-- | doc/src/sgml/datetime.sgml | 20 |
1 files changed, 9 insertions, 11 deletions
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> -=> SELECT '2018-11-04 02:30'::timestamptz; +=> SELECT '2018-11-04 01:30'::timestamptz; timestamptz ------------------------ - 2018-11-04 02:30:00-05 + 2018-11-04 01: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. + 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 matter by - specifying daylight-savings time: + as if it were standard time (UTC-5). We can force the other + interpretation by specifying daylight-savings time: <programlisting> -=> SELECT '2018-11-04 02:30 EDT'::timestamptz; +=> SELECT '2018-11-04 01: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> |