2011-01-26 6 views
11

注:質問は以前に存在したものを削除し、関連する情報のみをここに入力しました。Django:タイムゾーンの問題

データベースサーバー(RH)のTIME_ZONE = "Europe/London"が指定されています。そして、Django settings.pyの中で、TIME_ZONE = "America/New_York"を指定します。

とは、私のモデルクラスでIが指定されています:

created = models.DateTimeField(editable=False,auto_now=False, auto_now_add=True) 
modified = models.DateTimeField(editable=False,auto_now=True, auto_now_add=True) 

私は、adminサイト内のデータを見て行くと、私の代わりに東のUTC/GMT時間を取得します。

私はDjangoのタイムゾーンとして "America/New_York"を指定して以来、常にDjangoによって自動的に調整されると思っていました。

助け/浄化が認められています。

おかげ エリックあなたが質問を編集したので

+0

これは何から得ますか? >>> import datetime >>> datetime.datetime.now() –

+0

私はちょうどSERVER情報を更新しました。タイムゾーンはOn Server Europe/Londonに設定されています。 –

+0

私はむしろAUTO_NOWを使用しません。タイムゾーンが設定されているデータベースサーバーに委任します。この方法では、ユーザーごとに異なるタイムゾーンを持つ柔軟性が失われます。 –

答えて

10

日付/時刻 'automagic'に依存することは危険です。これらのauto_addモデルのパラメータはトラップです。あなたが扱っているタイムゾーンを常に理解してください。 Pythonは、datetimeオブジェクトにtzinfoメンバを付けることで、これを簡単にします。これらのオブジェクトはデフォルトでは「ナイーブ」ですが、tzinfoの詳細を常に添付することをお勧めします。まだPythonには、python-dateutilまたはpytz(私が使っているもの)のいずれかの補足が必要です。しかし、普遍的なルールがあります - あなたのdatetimesは常にUTCとしてデータベースに格納します。

なぜですか?あなたのユーザーは、地元の人々、携帯電話、ラップトップの旅行中である可能性があります。サーバーは、異なるタイムゾーンで誤って構成またはミラーリングされています。非常に多くの頭痛。 Datetimesは素朴であってはならず、(データベースのように)コンテキストが必要な場合は、テーブルにタイムゾーンフィールドも含めてください。

あなたの場合はそうです。

  1. auto_nowフィールドを使用しないで、代わりにカスタムsave()を使用してください。
  2. データベースにUTCを保存します。
  3. タイムゾーン(ユーザーイベントなど)を知る必要がある場合は、データベースにタイムゾーンも格納します。あなたがpytzを使用している場合
  4. が必要/要求されたタイムゾーン

に変換し、localize()方法が素晴らしいです。 Pythonのdatetimeオブジェクトは有用なreplace()とastimezone()を持っています。

データベースがタイムゾーンが未知(MySQLのような)である場合は、データベースコネクタがtz対応オブジェクトを処理できないため、datetimesがUTCであることを確認してからreplace(tzinfo = None)を使用してください。

ここにはthreadのDjangoのauto_nowフィールドの詳細があります。

0

、私はDjangoは、あなたのデシベルのタイムゾーンを制御することはできません:)私の答えを編集しますので、これを修正する方法は、あなたのデシベルのタイムゾーンを更新することです。 MySQLの場合、このクエリを実行します。

SELECT @@global.time_zone, @@session.time_zone;

これはあなたのケースでは「ヨーロッパ/ロンドン」を意味し、あなたの問題の原因これは、デフォルトでSYSTEM, SYSTEMを返す必要があります。今、あなたがこれを確認したことを、このページに最初のコメントの指示に従ってください:あなたは変更を有効にするには、タイムゾーンを更新した後

http://dev.mysql.com/doc/refman/5.5/en/time-zone-support.html

は、MySQLサーバを再起動することを忘れないでください。

+0

DBがタイムゾーンオフセットを格納している限り(MySQLについてはわかりませんが、Postgresはこれを「タイムゾーン付きタイムゾーン」データ型で行います)、DjangoはDB設定を気にするべきではありません。 DjangoはかなりDBに無関係だと考えていますが、Ericは実行しているDBサーバー(名前とバージョン)を指定する必要があります。これはデバッグに役立ちます。 – drdaeman

1

auto_now_add = Trueと言うと、その値はdjangoサーバーではなくデータベースサーバーによって追加されます。したがって、データベースサーバーにタイムゾーンを設定する必要があります。

3

まず、データをUTCとして保存しておくとよいでしょう。

私はこれを聞かせてください、ESTで時間が必要なのはなぜですか、これはエンドユーザー向けですか、サーバー上でロジックを実行する必要がありESTでそれを必要としますか?

エンドユーザー向けの場合、簡単な修正は、ユーザーのブラウザが正しい時刻に変換を処理するようにすることです。あなたは時間を持っているしたい場合は、他の一方で、今

var date_obj = new Date({{ timestamp }}); 
var datetime_string = date_obj.toString(); 
// the datetime_string will be in the users local timezone 

timestamp = time.mktime(datetime_obj.timetuple()) * 1000 

をし、Webページ上のDateオブジェクトをインスタンス化:サーバー上のタイムスタンプにdatetimeオブジェクトに変換サーバー上の正しいゾーンに配置し、ロジックを実行することができます。 python-dateutilのヘルプを使用することをお勧めします。それはあなたが簡単に別のタイムゾーンにスワップすることができます:あなたが本当にしたいESTで日時を格納する場合

from datetime import datetime 
from dateutil import zoneinfo 

from_zone = zoneinfo.gettz('UTC') 
to_zone = zoneinfo.gettz('America/New_York') 

utc = created # your datetime object from the db 


# Tell the datetime object that it's in UTC time zone since 
# datetime objects are 'naive' by default 
utc = utc.replace(tzinfo=from_zone) 

# Convert time zone 
eastern_time = utc.aztimezone(to_zone) 

、あなたは(アジャイヤダヴとgorusが言ったように)DBサーバー上の時刻を変更する必要があります。なぜあなたはESTとしてそれらを保存したいのかわかりませんが、もう一度私はあなたのアプリケーションが何であるか分かりません。

+0

トッド、私の質問は完全ではなかったと思う。しかし、私はあなたのポイントを見て、彼らは良いものです。私は現在のプロジェクトでいくつかの例を使用します。ありがとう! –

関連する問題