2012-03-24 [長年日記]

tracでepoch time をちゃんと扱いたい (日付の表示が変になっちゃう。の続き)

チケットの作成日などの日付フィールドは、date, time, datetime, created, modified といった特定のカラム名の場合だけ 日付文字列(YYYY-MM-DDなど)で表示され、それ以外は unixtimeである整数値(16桁の数値)で表示されてしまうという問題がある。具体的には、tracのレポートで、チケットの作成日を created 以外のカラム名で表示しようとした際に、16桁の数字で表示されてしまう。

これを解決するために、Genshiのメソッドをサーバ側で使って変換するプラグインを作ってみた。EpochFieldPlugin まだ詰めが甘いところがある。

ついでに、時刻を扱うカスタムフィールドを作ってみた。

trac-hacks.org にある DateFieldPluginは日付を扱うカスタムフィールドを作れるのだが、時刻を扱うことができない。そこで、時刻を扱うカスタムフィールドに取り組んでみた。

UI部分はjquery.datetimeentry.jsというよさげなのを見つけたので、それで実装してみている。

まだ作りかけ。フィールド名をソースに直書きして動作確認中。

tracってユーザごとにタイムゾーンを指定できるので、時刻を扱う場合はユーザごとのタイムゾーンを意識しないといけない。日本で「正午」と入力したら、中国では「午前11時」と扱われなければいけない。

だとしたら、サーバ上では epoch time で扱い、表示する際にはユーザのタイムゾーンに応じて時刻を調整して表示してやればいい。

JavaScriptで実装してやろう。簡単かんたん……。

あれ。時差って結構大変だ。

これって本来、日付でもきちんと考えないといけないことなのでは。日本で 「3月24日」と入力したら、北米西海岸だったら「3月23日」だったりするのでは。

とか考えていったら、「isdst」とかいうメソッドにぶちあたった。なんだこれー。GMT+0900 だけでは語れない世界がそこにあるらしい……。

Pythonでは pytzで解決できるらしいが、JavaScript側で解決しようとしても適当なライブラリが見つからない。ううむー。

元データを探してみた。Time-zone database down によれば、ちょっと前にややこしいことがあったらしいが、現時点ではIANAのtime-zonesにあるのが最新ぽい。

で。中を見てみたら、"2dst"とかいう文字がある! サマータイムを二段階やってる! まじっすか。……がっつり読んでみたら、1940年代にやってたらしく、1970年以降にはそういうのはないみたい。でも、「4月の最後の日曜日から」とかいう感じで、単純には実装できなさそう。うーん。

Olson javascript で検索すると はてぶが見つかるが、その先が 404 Not Found だ。うーん。方針変更が必要かもー。

続きはこちら。

解決編


«前の日記(2012-01-14) 最新 次の日記(2012-03-31)»