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

[Yukio USUDA]

臼田です

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

臼田幸生