ふなばです。

>まあ，タイムゾーンを解釈しないのは許せる妥協だとして，98年問
>題はちょっと考えないといけませんね．いや，最初に考えなかった
>私がいけないんですけど．

では考えることにしましょう。

>というのもUNIXのtm構造体がyearは「西暦−1900」という定義を採
>用しているので，rubyもTimeクラスなどで基本的にそれを踏襲して
>います．以前のparsedateはその辺をほんの少し意識していました
>が，今後はそことの関係をどうするか決めておかないといけません
>ね．まあ，選択肢は

Perl 的という印象があります (この話は今度にしますが)。Ruby の Time ク
ラスは  UNIX そのままで (それほど簡単でもないけど)、それはそれで判りや
すく、便利なこともあるのだろうなと思います。もしかすると、 Ruby では大
切なことなのかもしれません。

Python では、UNIX くささが減って、年はちゃんと西暦であり、月はちゃんと
"1" から始まっています。こちらのほうが一般性がありそうですが、 Ruby に
勧められるかわかりません。Python としては正しいような気がしますが。

>  * Timeクラスの年表示を西暦にする

これはこれまでの Time クラスの考えを変えることになりますからね。Time
クラスの月も "1" から始まることにしたっていいという意見がでてくるかも
しれない。それをどう考えるでしょうか。

>  * parsedateとtmの表示は無関係と宣言する

今までも、あきらかに違っていたんですよね。宣言はなかったかもしれないけ
ど。lib/parsedate.rb の月は "1" から始まっていたし、年月日しかなかった。
じつは僕は lib/date.rb との関係のほうが気になっていました。 このふたつ
はかなり広汎な用途に対応することもできたはずですが、 Time クラスとの関
係性を重視するなら、それは諦めるべきですかね。なにかは捨てなくちゃなら
なくなりそうです。

僕としては無難でラクということもあって  (一番の理由は他にありますが)、
漠然と無関係な一般性のある実装というふうに考えてたフシがありますね (勝
手ですね)。 関係があるとしたらキチンとした解釈がなくちゃならない。やっ
ぱり、タイムゾーンも解釈できなきゃ、結局はそこでリンクが切れちゃうわけ
だから、それも必要になるんじゃないかと思います。

>  * parsedateも(適当に推測した西暦から)-1900した値を返す

今の Time を基本に考えるというなら、これでいいのかもしれません。作者は
そうしたいと考えるだろうと思います (違うかな)。

lib/parsedate.rb がなにを対象にしているのか、 あきらかでないのですが、
こう考えているのかもしれない。 その書式はどうであれ、それは time(2) が
発行するもので、その範囲だけ考えておけばいいという考えです。そう、人間
が入力したものをあつかおうという考えはないかもしれない。しかも、発行さ
れ、これから走査しようというからには、郵便物の消印やらタイムカードの時
刻印と同じことで、基本的に過去のものである。だとしたら、システムがうま
く稼働しているうちは lib/parsedate.rb も基本的には問題ない。じつは言葉
になっていないだけで、これくらいまで対象が限定されているフシもある。あ
らためて、こういって構わないならこれでイイといえるのかもしれない。

--Tadayoshi Funaba