2006年11月 4日

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

臼田です

On 2006/11/04, at 1:18, Tadamasa Teranishi wrote:

> 寺西です。
>
> Yukio USUDA wrote:
>>

>>> とりあえずインデックスのフォーマットとして 2038 年までの
>>> 対応となり
>>> ますので、time_tが64bitな環境でエラーが起きなかっ
>>> たとしても、
>>> インデックスにイリーガルなデータが入るという問題が起こります。
>>>
>> インデックスの64bit対応も先の問題であるのでしょうが。
>> NMZ.field.date のフォーマットであればイリーガル
>> な表現にはならないのではないでしょうか。
>
> いいえ。
> インデックスは異なるプラットフォームで共通のフォーマットですの
> で、
> time_t が 64bit のマシンだからといって、拡張してはなりま
> せん。
>
> なお、NMZ.field.date は既にただの文字列ではなく、
> NMZ.t や
> NMZ.field.utc に影響する値です。

確かにNMZ.t のフォーマットを変えないと2038年問題は
直せないので手を加えないほうがよいですね。

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

>> mknmz の初期処理のどこかで OS が 2038 年問題に対応
>> しているかどうかを異常終了しない時刻関数を用いて
>> 確かめておき日付フィールドを捨てるか残すかの判断
>> にしてはどうでしょう。
>
> 上述の通りそれはダメです。
>
> しかし、Namazu 2.2.x であれば、フォーマットを拡張するこ
> とは可能です。
> その値を利用する部分は 2038 年以降の日時が扱える
> OS 以外でも対応
> できるようなルーチンは作らなければなりませんが。

2.2.x での TODO ですね。
また、時刻を記録する場所が3つもあるのはさすがに冗長
な気がするので 2.2.x ではフォーマット拡張と合わせて
整理統合が必要でしょうね。

臼田幸生
_______________________________________________
Namazu-devel-ja mailing list
Namazu-devel-ja@xxxxx
http://www.namazu.org/cgi-bin/mailman/listinfo/namazu-devel-ja

投稿者 xml-rpc : 2006年11月 4日 08:48
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/48876
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。