[ruby-list:10026] Re: man-1.1/Marshal.html

前田@リコーです。

> いや、ここでの話に NTP は関係ないですよ。Marshal などで、Time を書き出
> しだときに、それってポータブルだって保証できるか、できないならばそう書
> いておいたほうがいいんじゃないかってことですから。

私はその前提がわかっていませんでした。どうもすみません。もう一度
元の投稿を読み直してきました。「ポータブルでないシステムもないと
は言い切れないが、普通はポータブルだ」ではいかんということなので
しょうか。

> 何度もいうようだけど、僕は Ruby がどのような方針であるのかハッキリさせ
> て、責任の範囲を明確にするのが望ましいということをいっているだけです。
> time(2) そのままです、でもよいとは思いますけど、だったら、1970年1月1日
> 云々は余計だといえましょう。徹底的に責任逃れしておくべきです :-)

うるう秒をきちんと管理するマシンを相手にしても保証されるような
「ポータビリティ」を提供する(……保証されるような場合でなければ
「ポータブル」という言葉を使わない)ことがRubyの使命とも思えない
のですが……。あるいはそれを使命とするかどうか決定することが

> Ruby がどのような方針であるのかハッキリさせ
> て、責任の範囲を明確にする

ということなのでしょうか? 

>>いずれにせよ、エンドユーザー(time(2)やTime.now.tv_secで時刻を得
>>る人)はうるう秒を気にしなくてよいはずです。
>
> うー、納得できない :-)
>
> 気にしなくてよい、というのは、NTP プロトコルな時間が支配しているから矛
> 盾は起らないという論理なんでしょうか。だとして、どうしてそういう前堤が
> なりたつんでしょう。

ええっと、私の言いたいことは、
  「うるう秒が原因でポータビリティーが得られなくて文句を言うとし
    たら、相手は自分のサイト(あるいはターゲットシステム)のシステ
    ム管理者であるべきで、Rubyの開発者やマニュアルライターではな
    い」
ということです。

> どっちにしても、「筈」では不足で、保証できないんなら、できないといって
> もらったほうがいいなあ。

わかってきました。未来の時刻に対して、
  ruby -e 'print Time.gm(1999)-Time.gm(1998,"12",31,23,59,59),"\n"'
の結果が1.0となることの説明ができるためには、PerlやPython式に
「うるう秒を無視した秒数」と定義するより良い方法はないように思え
ます。

う〜ん、もうちょっとよく考えます。
    ある時刻の演算において、Timeの定義域全域で加減算を矛盾なく定
    義するためには、未来のうるう秒は無視せざるを得ない(うるう秒
    がいつ入るかは予測できないから)。次に、ある時刻定数AとBに対
    するA-Bが、すべての時刻において同一の値となるためには、過去
    のうるう秒も無視せざるを得ない(さもないと、1999年元日直前の
    うるう秒がシステムに登録された瞬間に、上の例の引き算の結果が
    1.0から2.0になってしまう。この「登録された瞬間」は実際のうる
    う秒の前かもしれないし後かもしれない)。Timeの加減算を保証す
    るなら、うるう秒を含まないことを保証しなければならない。
「Timeの加減算を定義するために、うるう秒はすべて無視する」として
よろしいのではないでしょうか。これで処理系の問題もなくなったので
はないでしょうか。処理系によってうまくいかない場合、「その処理系
にRubyがうまく移植できていない」という問題に還元されることになり
ます(NTPが云々というのは私の誤解として全部忘れてください)。

epochが1970年かどうかは別の問題として残ります(MacOSでは1904年だ
ということです(伝聞))。ちなみに、Timeの解説に関して言えば、1970
年以前の時刻(負の時刻)が扱えない旨は書くべきでしょうね。

-------------------------------  Vulture       LRM20   .□||□.   LRM20
 前田 薫 [e-mail]   75t 175km/h     Md+  o'□||□`o  Md+
 (株)リコー ソフトウェア研究所   HeatSink 18  LG Sm+   .=X~~X=.   Sm+ LG
-------------------------------  Armor 2195           _|_    _|_