1

最近、タイムゾーン処理の使用を開始するために、Django プロジェクトを 1.3 から 1.5 にアップグレードしました。私はバカなので、Django のタイムゾーンは UTC ではなく「America/NewYork」に設定されていました。Django のタイムゾーン サポートをオンにすると、Postgres が自動的に UTC に設定されます。現在、直接 SQL クエリを実行する際に問題が発生しています。タイムゾーンのフィルタリングを正しく取得できないようです。これが私がやっていることです:

  1. ユーザーフォームからタイムスタンプフィールドを受け入れる
  2. 私の見解でそれをUTCに交換するstamp.astimezone(timezone('UTC'))
  3. start.strftime('%Y-%m-%d %H:%M:00%z')django.db.connection のカーソルを使用して生の SQL クエリでそれをパラメータ () として渡す

実行されるクエリ (コンソールへのログ記録) は正しいように見えます。

SELECT to_char(created, 'YYYY-MM-DD HH12:MIam'),
COALESCE(heat_flow_1, 0.0) / 1000.0, COALESCE(heat_flow_2, 0.0) / 1000.0,
COALESCE(heat_flow_3, 0.0) / 1000.0
FROM results_flattenedresponse
WHERE installation_id = '66'
AND created BETWEEN TIMESTAMPTZ '2013-04-26 13:00:00+0000' AND TIMESTAMPTZ '2013-04-26 16:00:00+0000'

それをコピーして PGAdmin に貼り付けると、探しているもの、午前 9 時 EDT から始まる一連の行が得られます。ただし、django.db.connection のカーソルから返されるデータセットには、すべての日付が 4 時間 (EDT と UTC の差) 先送りされています。残りのデータは実際には正しいですが、日付は UTC として扱われ、ユーザーのアクティブなタイムゾーンにプッシュされます (非アクティブ化を呼び出しても)。今、これを修正しようとして、悪いアイデアがぐちゃぐちゃに絡み合っているような気がするので、どの部分が良いアイデアで、何が悪いのかわかりません。

編集/更新

ここで他の多くのことを試してみましたが、まだ悪い結果が得られていますが、データベースに直接クエリを実行した場合のみです。上記のステップ 2 と 3 のものは重要ではないようです。私が見ることができる1つの簡単な修正は、実際にクエリでタイムゾーンを設定することです。たとえば、SET timezone='America/New_York';それを元に戻しますが、それはデータの整合性にとって非常に悪い考えのようです.

もう 1 つの奇妙な点: Django のタイムゾーン設定を UTC に設定しましたが、ローカル コピーをダウンロードしてデータを見ると、まだ America/New_York に設定されているかのようにマークされています。それが私のローカルサーバーの設定によるものなのか、それとも 2 番目の (デフォルトではない) データベースに挿入されたときにデータが Django によって適切にローカライズされていないというバグがあるのか​​ はわかりません。私の問題は解決したと思います。

4

1 に答える 1

1

サーバーは現在UTC時間であるため、作成されたものはデフォルトでUTCとして返されるため、最初のビットは

SELECT to_char(created AT TIME ZONE %s, 'YYYY-MM-DD HH12:MIam')

見たいタイムゾーンを渡します。これは最善の方法ではありませんが、関連するタイムゾーンをプロパティとして持つオブジェクト内ですべてのクエリが実行されるため、ここではうまくいきます。

于 2013-05-01T14:49:54.083 に答える