日付/時刻文字列が構文的に正しいが、フィールドの範囲外の値を含んでいる場合、通常、エラーとなります。 たとえば、2月31日を指定した入力は受け付けられません。

夏時間の移行期間では、一見正しく見えるタイムスタンプ文字列が、存在しない、あるいは曖昧なタイムスタンプを表現してしまうことがあります。 そのような場合はエラーで弾くことはせず、どのUTCオフセットを適用するかを決定する過程で曖昧さが解消されます。 たとえばTimeZoneパラメータがAmerica/New_Yorkに設定されているとして、以下の例を考えてみましょう。

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

その時間帯では、その日は春に時刻を進める(spring-forward transition)日なので、標準時で2:30AMは存在しません。 2AM ESTから3AM EDTに時計がジャンプするからです。 PostgreSQLはあたかも標準時(UTC-5)で時刻を与えられたかのように解釈し、続いて3:30AM EDT (UTC-4)として表示しました。

逆に、秋に時刻を戻す移行期間(fall-back transition)の振る舞いを考えます。

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

その日は、2:30AMに対してふた通りの解釈が可能でした。 まず2:30AM EDTがあり、1時間後の標準時への遡行ののち、2:30AM ESTとなりました。 ここでもPostgreSQLはあたかも標準時(UTC-5)で時刻を与えられたかのように解釈しました。 夏時間を指定することにより、動作を強制できます。

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

このタイムスタンプは2:30 UTC-4あるいは1:30 UTC-5のどちらでも正しく表示できます。 タイムスタンプの出力コードは後者を選びました。

このような場合に適用される正確なルールは次のようなものです。 夏時間で時刻を進める移行期間に入る不正なタイムスタンプは、移行期間の直前の時間帯に適用されるUTCオフセットが割り当てられます。 一方、時刻を戻す移行期間の前あるいは後のどちらでにでも入る可能性のある不正なタイムスタンプは、移行期間の後に相当するUTCオフセットが割り当てられます。 ほとんどの時間帯にとってこれは「疑わしければ標準時間として解釈する」と言うのと同じです。

どんな場合でも、数字のUTCオフセットを使うか、あるいは時間帯省略形に関連する固定のUTCオフセットを使って、タイムスタンプに付随するUTCオフセットを明示的に指定できます。 ここで説明したルールは、ある時間帯のUTCオフセットが変動し、UTCオフセットを推測する必要がある場合にのみ適用されます。