0

3つの列を持つテーブルprovidersがあります（より多くの列が含まれていますが、この場合は重要ではありません）：

  • starttime、あなたが彼に連絡できる開始時間。
  • endtime、あなたが彼に連絡できる最後の時間。
  • region_id、プロバイダーが存在する地域。米国の場合：カリフォルニア、テキサスなど。英国の場合：イングランド、スコットランドなど。

starttimeとendtimeはタイムゾーン列のない時間ですが、「間接的に」、それらの値にはプロバイダーが存在する地域のタイムゾーンがあります。例えば：

starttime | endtime  | region_id (time zone of region) | "real" st | "real" et
----------|----------|---------------------------------|-----------|-----------
 03:00:00 | 17:00:00 |     1     (EGT => -1)           | 02:00:00  | 16:00:00

多くの場合、時間範囲が現在のサーバー時間内にあるサプライヤーのリストを取得する必要があります（タイムゾーン変換を考慮に入れて）。問題は、タイムゾーンが「一定」ではないことです。つまり、夏の間はタイムゾーンが変更される可能性があります。ただし、この変更は地域に固有のものであり、常に同時に実行されるとは限りません。EGT<=> EGST、ART<=>ARSTなど。

質問は：

1. Webサービスを使用して、地域のタイムゾーンを頻繁に更新する必要がありますか？提供できるWebサービスを知っている人はいますか？

2.この問題を解決するためのより良いアプローチはありますか？

前もって感謝します。

アップデート

私が得ようとしているものを明確にするために例を挙げます。表providersで私はこの記録を見つけました：

idproviders | starttime | endtime  | region_id
------------|-----------|----------|-----------
      1     |  03:00:00 | 17:00:00 |   23 (Texas)
      2     |  04:00:00 | 18:00:00 |   23 (Texas)

1月にクエリを実行すると、次の情報が表示されます。

  • サーバー時間（UTCオフセット）=0時間
  • テキサスプロバイダー（UTCオフセット）= +1時間
  • サーバー時間=02:00:00

次の結果が得られるはずです：idproviders = 1

6月にクエリを実行すると、次の情報が表示されます。

  • サーバー時間（UTCオフセット）=0時間
  • テキサスプロバイダー（UTCオフセット）= +2時間（現地時間は変更されていませんが、タイムゾーンは変更されています）
  • サーバー時間=02:00:00

次の結果が得られるはずです：idproviders=1および2

4

2 に答える 2

2

ID があるという事実以外に、「地域」レコードに関する詳細を提供していません。

timezone varchar NOT NULLそれでも、テーブルに列を追加できregionsます (1 つあると仮定します)。所有している各地域にタイム ゾーン名を割り当てる必要があります。これは簡単な作業ではないかもしれません。

その後、次のクエリを使用して、営業時間内にあるプロバイダーを見つけることができます。

SELECT p.* FROM providers AS p LEFT JOIN regions AS r ON (r.id = p.region_id)
WHERE (now() AT TIME ZONE r.timezone)::time BETWEEN p.start_timestamp AND p.end_timestamp;

now() AT TIME ZONE r.timezone現在のサーバー時刻を地域に割り当てられたタイムゾーンに変換します。

設定例: サーバーはロンドンにあり、プロバイダーはパナマにあります。
例 1: サーバーの時刻は 2012-01-01 18:00:00 です。は、プロバイダのおよび と比較できるパナマの現在時刻'2012-01-01 18:00:00' AT TIME ZONE 'America/Panama'を返します。 ケース 2 の例: サーバーの時刻は 2012-08-01 18:00:00 で、DST を観察します。ただし、パナマは赤道に近く、日の長さがあまり変わらないため、DST を観察しません。それでも、は Panama: の正しい現在時刻を返します。Postgres は、8 月のあなたの時刻が DST を遵守していることを認識していますが、パナマの時刻はそうではありません。2012-01-01 13:00:00start_timestampend_timestamp
'2012-08-01 18:00:00' AT TIME ZONE 'America/Panama'2012-08-01 12:00:00

私はあなたのためにそれをより明確にする方法がわかりません.

于 2012-09-18T11:59:09.320 に答える
1

time(ではなくtimestamp) と "Texas" のような地域しかない場合は、そもそも運が悪いです。これが夏時間であるかどうかの情報はありません。あなたはおそらく知ることはできません。

コンポーネントのみを使用する場合でも、そのフィールドをtimestamp with time zone( ) にします。これにより、誰かが値を入力するたびに、内部で UTC タイムスタンプに変換され (DST が自動的に考慮されます)、明確な情報が得られます。値は、現在のタイムゾーン設定に従って自動的に表示され (どこにいても)、誰にとっても適切です。テストするときは、単純に時間にキャストできます。timestamptztime

SELECT start_timestamp::time

これにより、同等のローカル timeが得られます（現在のタイムゾーン設定に従って）。すべてがとても簡単になります。この関連する回答
で、PostgreSQL がタイムスタンプを処理する方法について詳しく説明します。

于 2012-09-18T13:32:37.680 に答える