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

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

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

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. <productname>PostgreSQL</productname> interprets the given time as if it were standard time (UTC-5), which then renders as 3:30AM EDT (UTC-4). その時間帯では、その日は春に時刻を進める(spring-forward transition)日なので、標準時で2:30AMは存在しません。 2AM ESTから3AM EDTに時計がジャンプするからです。 PostgreSQLはあたかも標準時(UTC-5)で時刻を与えられたかのように解釈し、続いて3:30AM EDT (UTC-4)として表示しました。

Conversely, consider the behavior during a fall-back transition: 逆に、秋に時刻を戻す移行期間(fall-back transition)の振る舞いを考えます。

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

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 other interpretation by specifying daylight-savings time: その日は、1:30AMに対してふた通りの解釈が可能でした。 まず1:30AM EDTがあり、2 AM EDTから1 AM ESTに遡行するので1時間後に1:30AM ESTがあります。 ここでもPostgreSQLはあたかも標準時(UTC-5)で時刻を与えられたかのように解釈しました。 夏時間を指定することにより、他の解釈を強制できます。

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

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

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