通常，如果日期/时间字符串在语法上有效但包含超出范围的字段值，将会 抛出错误。例如，指定 2 月 31 日的输入会被拒绝。

在夏令时转换期间，一个看似有效的时间戳字符串可能表示一个不存在或 有歧义的时间戳。这类情况不会被拒绝；歧义通过确定要应用哪个 UTC 偏移来消解。例如，假设 TimeZone 参数被设 为 America/New_York，考虑

=> SELECT '2018-03-11 02:30'::timestamptz;
      timestamptz
------------------------
 2018-03-11 03:30:00-04
(1 row)

由于那一天是该时区的春季拨快转换日，民用时间中不存在凌晨 2:30 这一时刻；时钟从东部标准时间凌晨 2 点直接跳到东部夏令时间凌晨 3 点。PostgreSQL 把给定的时间解释为 标准时间（UTC-5），于是显示为东部夏令时间的 3:30AM（UTC-4）。

相反，考虑秋季拨回转换期间的行为：

=> SELECT '2018-11-04 01:30'::timestamptz;
      timestamptz
------------------------
 2018-11-04 01:30:00-05
(1 row)

在那个日期，凌晨 1:30 有两种可能的解释；先是东部夏令时间的 1:30AM，然后一小时后，当时钟从东部夏令时间凌晨 2 点拨回到东部标准 时间凌晨 1 点，又出现了一次东部标准时间的 1:30AM。 同样，PostgreSQL 把给定的时间解释为 标准时间（UTC-5）。我们可以通过指定夏令时来强制另一种 解释：

=> SELECT '2018-11-04 01:30 EDT'::timestamptz;
      timestamptz
------------------------
 2018-11-04 01:30:00-04
(1 row)

在这类情况下应用的精确规则是：看似落在拨快型夏令时转换内的无效 时间戳被赋予转换之前该时区通行的 UTC 偏移，而可能落在拨回型转换 任意一侧的歧义时间戳被赋予转换之后通行的 UTC 偏移。 在大多数时区中，这等价于说 “有疑问时优先采用标准时间的解释”。

在所有情况下，与时间戳关联的 UTC 偏移都可以被显式指定，方法是使用 数字 UTC 偏移或对应于固定 UTC 偏移的时区缩写。 刚才给出的规则只在必须为偏移会变化的时区推断 UTC 偏移时 适用。