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

[Yukio USUDA]

臼田です

On 2006/11/03, at 2:45, Tadamasa Teranishi wrote:

>
>> time_tが64bitだぜ、といったオペレーティング・システム 
>> で、はるかな未来
>> までTime::Localのtimegm()がちゃんとサポートしてる 
>> といった場合でない限
>> り、同様な問題は起きるんではないでしょうか。
>
> とりあえずインデックスのフォーマットとして 2038 年までの 
> 対応となり
> ますので、time_tが64bitな環境でエラーが起きなかっ 
> たとしても、
> インデックスにイリーガルなデータが入るという問題が起こります。
>
インデックスの64bit対応も先の問題であるのでしょうが。
NMZ.field.date のフォーマットであればイリーガル
な表現にはならないのではないでしょうか。


>> いずれにしろ、日付をparseできない理由でエラーで終わって 
>> しまうのは嬉し
>> くないと思います。
>
> とは言え、どう対応するのが正しいというものがあるわけではないと 
> ころが
> 難しいところです。
>
> 雑ですが、とりあえず 2038年より未来なら日付フィールドの 
> 情報を捨てる
> ことにします。

現状は日付フィールドの情報を捨てるのが妥当と思いますが
2038年問題の芽になるので OS が対応したらいずれ
戻さなければいけないものになります。
mknmz の初期処理のどこかで OS が 2038 年問題に対応
しているかどうかを異常終了しない時刻関数を用いて
確かめておき日付フィールドを捨てるか残すかの判断
にしてはどうでしょう。

一部の OS では既に 2038年以降の日付にも対応している 
ようです。
http://ccsf.homeunix.org/fn-b.cgi?msgid=%3C20061014201649.77bc7fad.tuc 
%40vfemail.net%3E


臼田幸生