解析時間がいかに不安定になるかについて、たくさんの投稿を読みました。ここで、ISO8601 形式のタイムスタンプを変換する信頼できる方法を思いついたと思います。
https://gist.github.com/3702066
最も重要な部分はastimezone(LOCALZONE)
、日付が解析されるときの呼び出しです。これにより、time.mktime() が正しいことを実行できるようになり、夏時間を適切に処理しているように見えます。
私が見逃した明らかな落とし穴はありますか?
解析時間がいかに不安定になるかについて、たくさんの投稿を読みました。ここで、ISO8601 形式のタイムスタンプを変換する信頼できる方法を思いついたと思います。
https://gist.github.com/3702066
最も重要な部分はastimezone(LOCALZONE)
、日付が解析されるときの呼び出しです。これにより、time.mktime() が正しいことを実行できるようになり、夏時間を適切に処理しているように見えます。
私が見逃した明らかな落とし穴はありますか?
あなたのコードは、夏時間への移行の直前または直後の時間でも機能しているように見えますが、場所のタイムゾーン オフセットが実際に変更されるまれなケースでは失敗する可能性があるのではないかと心配しています。ただし、テストする例はありません。
したがって、うまくいく場合でも (またはほとんど常にうまくいく場合でも)、UTC 時刻文字列を UTC タイムスタンプに変換する方法は、何らかの形で現地時間を含む、または通過させるのはおかしいと思います。ローカル タイム ゾーンは関係ありません。これは望ましくない依存関係です。私はあなたが狂っていると言っているのではありません。与えられた API を操作しようとしているだけで、C ライブラリの時間 API の設計が不適切です。
mktime()
幸いなことに、Python は、C ライブラリが提供すべきものに代わるものを提供しています: calendar.timegm()
. この関数を使用すると、関数を次のように書き直すことができます。
parsed = parse_date(timestamp)
timetuple = parsed.timetuple()
return calendar.timegm(timetuple)
現地時間が含まれていないため、これは pytz への依存も取り除き、誰かのローカル タイムゾーンのあいまいなアーティファクトが望ましくない効果を引き起こすというしつこい疑いも取り除きます。