begriffs open source - ai-pg/blob - full-docs/txt/datetime-invalid-input.txt

   1
   2 B.2. Handling of Invalid or Ambiguous Timestamps #
   3
   4    Ordinarily, if a date/time string is syntactically valid but contains
   5    out-of-range field values, an error will be thrown. For example, input
   6    specifying the 31st of February will be rejected.
   7
   8    During a daylight-savings-time transition, it is possible for a
   9    seemingly valid timestamp string to represent a nonexistent or
  10    ambiguous timestamp. Such cases are not rejected; the ambiguity is
  11    resolved by determining which UTC offset to apply. For example,
  12    supposing that the TimeZone parameter is set to America/New_York,
  13    consider
  14 => SELECT '2018-03-11 02:30'::timestamptz;
  15       timestamptz
  16 ------------------------
  17  2018-03-11 03:30:00-04
  18 (1 row)
  19
  20    Because that day was a spring-forward transition date in that time
  21    zone, there was no civil time instant 2:30AM; clocks jumped forward
  22    from 2AM EST to 3AM EDT. PostgreSQL interprets the given time as if it
  23    were standard time (UTC-5), which then renders as 3:30AM EDT (UTC-4).
  24
  25    Conversely, consider the behavior during a fall-back transition:
  26 => SELECT '2018-11-04 01:30'::timestamptz;
  27       timestamptz
  28 ------------------------
  29  2018-11-04 01:30:00-05
  30 (1 row)
  31
  32    On that date, there were two possible interpretations of 1:30AM; there
  33    was 1:30AM EDT, and then an hour later after clocks jumped back from
  34    2AM EDT to 1AM EST, there was 1:30AM EST. Again, PostgreSQL interprets
  35    the given time as if it were standard time (UTC-5). We can force the
  36    other interpretation by specifying daylight-savings time:
  37 => SELECT '2018-11-04 01:30 EDT'::timestamptz;
  38       timestamptz
  39 ------------------------
  40  2018-11-04 01:30:00-04
  41 (1 row)
  42
  43    The precise rule that is applied in such cases is that an invalid
  44    timestamp that appears to fall within a jump-forward daylight savings
  45    transition is assigned the UTC offset that prevailed in the time zone
  46    just before the transition, while an ambiguous timestamp that could
  47    fall on either side of a jump-back transition is assigned the UTC
  48    offset that prevailed just after the transition. In most time zones
  49    this is equivalent to saying that “the standard-time interpretation is
  50    preferred when in doubt”.
  51
  52    In all cases, the UTC offset associated with a timestamp can be
  53    specified explicitly, using either a numeric UTC offset or a time zone
  54    abbreviation that corresponds to a fixed UTC offset. The rule just
  55    given applies only when it is necessary to infer a UTC offset for a
  56    time zone in which the offset varies.