diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2022-01-10 11:46:16 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2022-01-10 11:46:25 -0500 |
| commit | 05cdda68f8f6e63cb87bc1776236d7619cd89fb7 (patch) | |
| tree | 4a78e1ea8e40a7925a837fadb872c74f535305db | |
| parent | 1cd46f168fda4d819e315eacf3d4f3d5aa84859c (diff) | |
| download | postgresql-05cdda68f8f6e63cb87bc1776236d7619cd89fb7.tar.gz postgresql-05cdda68f8f6e63cb87bc1776236d7619cd89fb7.zip | |
Doc: fix bogus example about ambiguous timestamps.
I had a brain fade in commit d32899157, and used 2:30AM as the
example timestamp for both spring-forward and fall-back cases.
But it's not actually ambiguous at all in the fall-back case,
because that transition is from 2AM to 1AM under USA rules.
Fix the example to use 1:30AM, which *is* ambiguous.
Noted while answering a question from Aleksander Alekseev.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/2191355.1641828552@sss.pgh.pa.us
| -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> |