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 だ。うーん。方針変更が必要かもー。
