[Namazu-devel-ja 1366] Re: Cannot handle date (49, 21, 03, 29, 8, 2099) at .. pl/time.pl

[Tadamasa Teranishi]

寺西です。

Yukio USUDA wrote:
> 
> ところで、STABLE の mknmz では NMZ.field.utc
> 用の修正が
> 入っているようですがpl/conf.pl の $SEARCH_FIELD には
> utc が標準では入っていないようです。
> 現在どういう扱いなのでしたっけ。

明確に示していなかったかもしれませんが、次のように考えています。

フィールド日付ソート機能を有効にする場合に utc をユーザーが
追加して使う。(言い換えると utc を追加しないとフィールド日付ソート
機能を有効にすることはできない。)
utc をデフォルトとしないのは、利用していない方のことを考えての
ことです。その人にとっては、インデックスが大きくなってしまうのを
避けるためです。
フィールド日付ソート機能はテンプレートの書き換えも必要となること
と、ソート速度の面で不利だという点で stable ではデフォルトとなって
いません。
 
> > しかし、Namazu 2.2.x であれば、フォーマットを拡張するこ
> > とは可能です。
> > その値を利用する部分は 2038 年以降の日時が扱える
> > OS 以外でも対応
> > できるようなルーチンは作らなければなりませんが。
> 
> 2.2.x での TODO ですね。
> また、時刻を記録する場所が３つもあるのはさすがに冗長
> な気がするので 2.2.x ではフォーマット拡張と合わせて
> 整理統合が必要でしょうね。

はい。
広い意味では、date の整理の前準備で冗長ではありますが、利便性と
互換性を考え utc フィールドを新設しました。しかし、これは 2.2.x で
整理することが可能なものです。

また、Namazu が扱える日付は、限られた幅のほぼ現在の時刻(メールが
送られた日付とか、ファイルが作成された日付とかを扱うのが目的)に
限られますが、2038年問題とは別に、紀元前何年とか、西暦2772年だと
かといったDBのように広範囲の値(DBで紀元前が扱えたかどうかは知ら
ないけど)が扱えると、日付の利用用途が広がって良いかと思って
います。
その辺りも含めて改良していきたいと考えています。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns ＠ asahi-net.or.jp
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E