3

dateutilライブラリを使用して日付文字列を解析していますが、奇妙な結果が得られます。次の日付文字列はすべて等しいと想定し、括弧内のタイムゾーンの省略形は実際にはオプションでしたが、それを削除するとまったく異なる値が得られます。

import datetime   
import dateutil.parser

parsed_d1 = dateutil.parser.parse('Sun May 13 2012 00:00:00 GMT-0400 (EDT)')   
parsed_d2 = dateutil.parser.parse('Sun May 13 2012 00:00:00 GMT-0400')   
parsed_d3 = dateutil.parser.parse('Sun May 13 2012 00:00:00-0400')   

print str(parsed_d1)   
print str(parsed_d2)   
print str(parsed_d3)

出力：

2012-05-13 00:00:00-04:00   
2012-05-13 00:00:00+04:00   
2012-05-13 00:00:00-04:00

ここで何が起こっているのか誰か説明できますか?

4

1 に答える 1

3

EDT は、英国の西にある米国向けです。日は東から昇る。そのため、太陽は米国よりも先に英国で頭上にあります。したがって、GMT を取得するには、EDT に 4 時間を追加する必要があります。これが、午後遅くまでに（英国の）両親に電話する必要がある理由です。そうしないと、両親は寝ています。つまり、「EDT +4 は GMT」です。

現在、このソースはhttp://bazaar.launchpad.net/~dateutil/dateutil/trunk/view/head:/dateutil/parser.pyにあり、解析に関連していると思われるコメントは次のようにGMT-0400述べています

# Check for something like GMT+3, or BRST+3. Notice
# that it doesn't mean "I am 3 hours after GMT", but
# "my time +3 is GMT". If found, we reverse the
# logic so that timezone parsing code will get it
# right.

つまり、GMT-0400「私の時間 -4 は GMT です」と同等です。これは上記と同じではありません。

また、コードを見ると、この後に末尾が(EDT)処理されているため、優先されます。そして、最後のシンプルな 3 番目のケースは、期待どおりに処理されると思います。-0400

言い換えれば (コードをスキャンすると、私にはそう思われます)、GMT-0400フォームはコード ドキュメントとして機能しますが、期待どおりには機能しません。その行は、他の 2 つと同等ではありません。

コードがこのように機能する理由がわかりません。私は読んだことを報告しているだけです。

最後に、そのコードの一般的なアプローチは、日付文字列全体をチャンクごとに処理し、さまざまなロジックをさまざまな場所に適用することです。さまざまな場所のロジックが一貫していることを確認するためのチェックはそれほど多くありません (したがって、最初の行の明らかな矛盾に対してエラーはスローされません)。個人的には、Python 独自の日付解析ルーチンを使用するライブラリを好みますが、さまざまな形式の文字列を試します。その方が信頼性が高いと思います (ただし、柔軟性が低い可能性があります)。

更新私はこの投稿を忘れていましたが、この返信を書いた後しばらくして、タイムゾーンの解析を処理するためにsimple-dateを書きました。それは、私が好むと言ったようなアプローチを取ります-賢くしようとする代わりに、pytz データベースで一致するものを検索します。

于 2012-05-14T02:13:19.267 に答える