Namazu-devel-ja(旧)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 日付順ソートに関して
寺西です。
"Hideyuki SHIRAI (白井秀行)" wrote:
>
> > しかし、$conf::SEARCH_FIELD に "date" を含めなかった時にまずい
> > ですね。ユーザーに削除されてしまうこともありえるので、その時でも
> > 有効になっていなければいけませんね。
>
> ですね。SEARCH_FIELD の default 値は
>
> $SEARCH_FIELD = "message-id|subject|from|date|uri|newsgroups|to|summary|size";
>
> ですが、他のもので必須なものってどうなっているのかしら？
あぁ。深みにはまってしまったような...。
> # ごめんなさい、調べる能力と調べている余力がありません。
いえいえ。
> もう一点 NMZ.field.xxx を積極的に使うときに気になるのは、
> $MAX_FIELD_LENGTH です。もし、こいつを極端に小さな値にしてあると、
> Date: フィールドが途中でちょん切れている可能性がありますので、
> mknmz のときに "Date:" は $MAX_FIELD_LENGTH の値によらず行末まで
> 有効にする、とか例外処理をしないとならないかも、です。
であれば、NMZ.field.date とは別のものを使うという手が良いかも
しれません。
フィルタ等で date をセットする時に rfc822time 形式で記録して
いますが、これをやめて time_t 型の整数(GMT が良いのかな、ローカル
タイムが良いかな)で保存するとかです。
例えば time とかという名前にでもして。
Log10(2^32) = 9.6... なので 10桁で収まりますから。
または NMZ.t のような別ファイルを用意するか、NMZ.t にタイム
スタンプと、date 情報の両方を入れるかですね。
> > 決して厳密にするつもりではなくて、mailutime なしに使える程度を
> > 考えています。
>
> はい、だけど mailutime を使用する/使用しないの選択はユーザが出来
> ますが、namazu に相当するものを組み込んじゃうとユーザの選択でど
> うのこうのではなくなりますから、可能な限り厳密に対応したほうが良
> いと思います。
確かに。ということで、まずは mailutime 側を先に修正する方針に
変えます。
ついでに、よみが浅く、根っこが深いとやっと気づいたので、Namazu に
関しては stable-2-0 ではなく、HEAD か別のブランチで考えた方が
良い気がしてきました。
> timezone の表記で許されているのは、今も昔も
>
> zone = (( "+" / "-" ) 4DIGIT) / obs-zone
> obs-zone = "UT" / "GMT" / ; Universal Time
> ; North American UT
> ; offsets
> "EST" / "EDT" / ; Eastern: - 5/ - 4
> "CST" / "CDT" / ; Central: - 6/ - 5
> "MST" / "MDT" / ; Mountain: - 7/ - 6
> "PST" / "PDT" / ; Pacific: - 8/ - 7
>
> %d65-73 / ; Military zones - "A"
> %d75-90 / ; through "I" and "K"
> %d97-105 / ; through "Z", both
> %d107-122 ; upper and lower case
そうなんですが、RFC に従っていないのも多々あるわけで...。
> だけですよ。って、Military zone は厳密に実装したとしても対応しな
> くても良いと思いますが :-)
これはパスしましょう。とりあえずは。
> > # JST とか....というのは冗談ですが。
>
> RFC2822 的には JST という timezone はないので、コンピュータが火
> を吐けば良いですね。(本当はファイルのタイムスタンプを使う、ですかな)
JST に関しては例えば、例えば野首さんのメールなんかがそうですし、
世の中にころがっていたりしますね。
http://www.namazu.org/ml/namazu-users-ja/msg02610.html
日本なので、JST は RFC になくても対応しておくべきだと思いますが、
その他の地域でもやっぱり RFC にないものを使っている場合もあると
予測できます。
その場合、GMT とみなすのか、またはローカルタイムとみなすのか、どちら
が良いのでしょう。
あと、timezone が無い場合は、GMT とみなすのか、ローカルタイムと
みなすのかどちらでしたでしょう。(後者かな?)
> > > Date: のソートなら、ファイルのタイムスタンプを使う方がマシ、と感
> > > じられます。
> >
> > mailutime で困る方はそういらっしゃらないようですし、ケースバイ
> > ケースだとは思います。
> > もっとも、いろいろな timezone を扱う方にはそうですよね。
>
> そうですね。ほうっておいてもメールは世界中から来ますからね。
ちらっとニュースを見たら、timezone ないとダメだなと痛感しました。
つうことは mailutime って、あまり使われていないってことなのか、
あまり日付(タイムスタンプでいいやということ?)は気にしていないのか、
ということなのかもしれません。
ついでに、ニュース関係で驚いたのは、
http://jbpe.tripod.com/rfcj/rfc1036.j.sjis.txt
に書いてある 2.1.2 Date のところです。
ctime(3)のフォーマットもありうるということでした。もはや現存して
いないと思いますが、確かに ctime(3) フォーマットも認識できると
何かと便利だとは思います。(ただし、英語のみ)
ここまで考えると、結果画面に出す日付の形式を変更したり、
ローカライズしたいとか、という欲望もでてきますね。
現状は、元ファイルに書かれた情報で表示されるので、統一感がない
ので、統一できるようにしても良いかと思っています。
(これは選択方式で。)
--
=====================================================================
寺西 忠勝(TADAMASA TERANISHI) yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E