summaryrefslogtreecommitdiffstats
path: root/doc/src/sgml/html/datetime-invalid-input.html
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-05-04 12:17:33 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-05-04 12:17:33 +0000
commit5e45211a64149b3c659b90ff2de6fa982a5a93ed (patch)
tree739caf8c461053357daa9f162bef34516c7bf452 /doc/src/sgml/html/datetime-invalid-input.html
parentInitial commit. (diff)
downloadpostgresql-15-5e45211a64149b3c659b90ff2de6fa982a5a93ed.tar.xz
postgresql-15-5e45211a64149b3c659b90ff2de6fa982a5a93ed.zip
Adding upstream version 15.5.upstream/15.5
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/src/sgml/html/datetime-invalid-input.html')
-rw-r--r--doc/src/sgml/html/datetime-invalid-input.html62
1 files changed, 62 insertions, 0 deletions
diff --git a/doc/src/sgml/html/datetime-invalid-input.html b/doc/src/sgml/html/datetime-invalid-input.html
new file mode 100644
index 0000000..16a0330
--- /dev/null
+++ b/doc/src/sgml/html/datetime-invalid-input.html
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>B.2. Handling of Invalid or Ambiguous Timestamps</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="datetime-input-rules.html" title="B.1. Date/Time Input Interpretation" /><link rel="next" href="datetime-keywords.html" title="B.3. Date/Time Key Words" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">B.2. Handling of Invalid or Ambiguous Timestamps</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="datetime-input-rules.html" title="B.1. Date/Time Input Interpretation">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="datetime-appendix.html" title="Appendix B. Date/Time Support">Up</a></td><th width="60%" align="center">Appendix B. Date/Time Support</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 15.5 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="datetime-keywords.html" title="B.3. Date/Time Key Words">Next</a></td></tr></table><hr /></div><div class="sect1" id="DATETIME-INVALID-INPUT"><div class="titlepage"><div><div><h2 class="title" style="clear: both">B.2. Handling of Invalid or Ambiguous Timestamps</h2></div></div></div><p>
+ Ordinarily, if a date/time string is syntactically valid but contains
+ out-of-range field values, an error will be thrown. For example, input
+ specifying the 31st of February will be rejected.
+ </p><p>
+ During a daylight-savings-time transition, it is possible for a
+ seemingly valid timestamp string to represent a nonexistent or ambiguous
+ timestamp. Such cases are not rejected; the ambiguity is resolved by
+ determining which UTC offset to apply. For example, supposing that the
+ <a class="xref" href="runtime-config-client.html#GUC-TIMEZONE">TimeZone</a> parameter is set
+ to <code class="literal">America/New_York</code>, consider
+</p><pre class="programlisting">
+=&gt; SELECT '2018-03-11 02:30'::timestamptz;
+ timestamptz
+------------------------
+ 2018-03-11 03:30:00-04
+(1 row)
+</pre><p>
+ Because that day was a spring-forward transition date in that time zone,
+ there was no civil time instant 2:30AM; clocks jumped forward from 2AM
+ EST to 3AM EDT. <span class="productname">PostgreSQL</span> interprets the
+ given time as if it were standard time (UTC-5), which then renders as
+ 3:30AM EDT (UTC-4).
+ </p><p>
+ Conversely, consider the behavior during a fall-back transition:
+</p><pre class="programlisting">
+=&gt; SELECT '2018-11-04 01:30'::timestamptz;
+ timestamptz
+------------------------
+ 2018-11-04 01:30:00-05
+(1 row)
+</pre><p>
+ 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, <span class="productname">PostgreSQL</span> interprets the given time
+ as if it were standard time (UTC-5). We can force the other
+ interpretation by specifying daylight-savings time:
+</p><pre class="programlisting">
+=&gt; SELECT '2018-11-04 01:30 EDT'::timestamptz;
+ timestamptz
+------------------------
+ 2018-11-04 01:30:00-04
+(1 row)
+</pre><p>
+ </p><p>
+ The precise rule that is applied in such cases is that an invalid
+ timestamp that appears to fall within a jump-forward daylight savings
+ transition is assigned the UTC offset that prevailed in the time zone
+ just before the transition, while an ambiguous timestamp that could fall
+ on either side of a jump-back transition is assigned the UTC offset that
+ prevailed just after the transition. In most time zones this is
+ equivalent to saying that <span class="quote">“<span class="quote">the standard-time interpretation is
+ preferred when in doubt</span>”</span>.
+ </p><p>
+ In all cases, the UTC offset associated with a timestamp can be
+ specified explicitly, using either a numeric UTC offset or a time zone
+ abbreviation that corresponds to a fixed UTC offset. The rule just
+ given applies only when it is necessary to infer a UTC offset for a time
+ zone in which the offset varies.
+ </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="datetime-input-rules.html" title="B.1. Date/Time Input Interpretation">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="datetime-appendix.html" title="Appendix B. Date/Time Support">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="datetime-keywords.html" title="B.3. Date/Time Key Words">Next</a></td></tr><tr><td width="40%" align="left" valign="top">B.1. Date/Time Input Interpretation </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 15.5 Documentation">Home</a></td><td width="40%" align="right" valign="top"> B.3. Date/Time Key Words</td></tr></table></div></body></html> \ No newline at end of file