Djangoのタイムゾーン設定がエポックタイムに影響するのはなぜですか？

私はPythonでもDjangoの第一人者でもないので、おそらく誰かが私よりもうまく答えることができます。とにかく推測します。

あなたはそれをDjangoのDateTimeFieldに保存していると言いました、参照したドキュメントによると、Python datetimeとして保存します。

datetimeのドキュメントを見る、重要なのは「ナイーブ」と「アウェア」の値の違いを理解することだと思います。

さらに調べてみると、この優れたリファレンスに出くわしました。。 2番目のセクション「ナイーブでアウェアな日時オブジェクト」を必ずお読みください。これは、これのどれだけがDjangoによって制御されているかについてのコンテキストを少し与えます。基本的に、USE_TZ = trueを設定します、Djangoに認識を使用するように要求しています ナイーブの代わりに日時

それで私はあなたの質問を振り返りました。あなたは次のことをしていると言いました：

dt = datetime.fromtimestamp(secs)
dt = dt.replace(tzinfo=utc)

fromtimestamp を見る関数のドキュメント、私はこのテキストを見つけました：

だから私はあなたがこれを行うことができると思います：

dt = datetime.fromtimestamp(secs, tz=utc)

次に、その関数のすぐ下に、ドキュメントにutcfromtimestampが表示されます。関数なので、多分それは次のようになります：

dt = datetime.utcfromtimestamp(secs)

Pythonについては、これらが同等かどうかを知るのに十分な知識はありませんが、どちらかが違いを生むかどうかを試してみることができます。

うまくいけば、これらの1つが違いを生むでしょう。そうでない場合は、私に知らせてください。私はJavaScriptと.Netの日付/時刻に精通していますが、Pythonなどの他のプラットフォームでこれらのニュアンスがどのように異なるかを常に知りたいと思っています。

更新

質問のMySQL部分については、このフィドルをご覧ください。。

CREATE TABLE foo (`date` DATETIME);
INSERT INTO foo (`date`) VALUES (FROM_UNIXTIME(1371131402));

SET TIME_ZONE="+00:00";
select `date`, UNIX_TIMESTAMP(`date`) from foo;

SET TIME_ZONE="+01:00";
select `date`, UNIX_TIMESTAMP(`date`) from foo;

結果：

DATE                           UNIX_TIMESTAMP(`DATE`)
June, 13 2013 13:50:02+0000    1371131402
June, 13 2013 13:50:02+0000    1371127802

UNIX_TIMESTAMPの動作は関数は実際にMySQLのTIME_ZONEの影響を受けます設定。それはドキュメントにあるので、それはそれほど驚くべきことではありません。驚くべきことは、datetimeの文字列出力です。設定に関係なく同じUTC値を持ちます。

これが私が起こっていると思うことです。 UNIX_TIMESTAMPのドキュメント機能、それは言う：

DATETIMEになる可能性があるとは言えないことに注意してください -DATETIMEの可能性があると表示されます 文字列 。したがって、実際の値は、関数に渡される前に暗黙的に文字列に変換されると思います。

では、この更新されたフィドルを見てください。明示的に変換します。

SET TIME_ZONE="+00:00";
select `date`, convert(`date`, char), UNIX_TIMESTAMP(convert(`date`, char)) from foo;

SET TIME_ZONE="+01:00";
select `date`, convert(`date`, char), UNIX_TIMESTAMP(convert(`date`, char)) from foo;

結果：

DATE                           CONVERT(`DATE`, CHAR)  UNIX_TIMESTAMP(CONVERT(`DATE`, CHAR))
June, 13 2013 13:50:02+0000    2013-06-13 13:50:02    1371131402
June, 13 2013 13:50:02+0000    2013-06-13 13:50:02    1371127802

文字データに変換すると、オフセットが取り除かれることがわかります。もちろん、UNIX_TIMESTAMPの場合は、当然のことです。この値を入力として受け取り、ローカルタイムゾーン設定を想定しているため、異なるUTCタイムスタンプを取得します。

これがあなたを助けるかどうかわからない。 Djangoが読み取りと書き込みの両方でMySQLをどのように呼び出しているかを正確に掘り下げる必要があります。実際にUNIX_TIMESTAMPを使用していますか関数？それとも、それはあなたがテストでしたことでしたか？