[#32727] require "./xxx" の「カレントディレクトリ」の意味 — Take_tk <ggb03124@...>

あるディレクトリαにあるスクリプトAに「require "./xxx"」と書いてあると、

21 messages 2001/12/03
[#32733] Re: require "./xxx" の「カレントディレクトリ」の意味 — matz@... (Yukihiro Matsumoto) 2001/12/03

まつもと ゆきひろです

[#32746] Re: require "./xxx" の「カレントディレクトリ」の意味 — Tanaka Akira <akr@...17n.org> 2001/12/04

In article <1007384829.854960.10474.nullmailer@ev.netlab.jp>,

[#32749] Re: require "./xxx" の「カレントディレクトリ」の意味 — Take_tk <ggb03124@...> 2001/12/04

たけ(tk)です。

[#32772] newdate — tadf@...

ふなばです。

108 messages 2001/12/04
[#32850] Re: newdate — Tanaka Akira <akr@...17n.org> 2001/12/10

In article <20011204234521G.tadf@kt.rim.or.jp>,

[#32855] Re: newdate — tadf@... 2001/12/10

ふなばです。

[#32859] Re: newdate — matz@... (Yukihiro Matsumoto) 2001/12/10

まつもと ゆきひろです

[#32860] Re: newdate — tadf@... 2001/12/10

ふなばです。

[#32889] Re: newdate — Tanaka Akira <akr@...17n.org> 2001/12/12

In article <20011210180612F.tadf@funaba.org>,

[#34281] Re: newdate — tadf@... 2002/03/10

ふなばです。

[#33661] when.exe の Ruby 化 (Re: newdate) — Takashi SUGA <suchowan@...> 2002/01/29

すいません。件名が変だったので、再送します。コメントをくださる方は、

[#32797] dir_config (mkmf.rb) のオプション指定の優先順位 — tamra@...

12 messages 2001/12/05
[#32798] Re: dir_config (mkmf.rb) のオプション指定の優先順位 — nobu.nakada@... 2001/12/06

なかだです。

[#32807] irb 0.8 release — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

21 messages 2001/12/07
[#32808] Re: irb 0.8 release — rubikitch <rubikitch@...> 2001/12/07

From: keiju@rational.com (Keiju ISHITSUKA)

[#32935] Ruby256 倍本 " 界道編 " — shukaku@...

23 messages 2001/12/15
[#32963] Re: Ruby256 倍本 " 界道編 " — Shin-ichiro HARA <sinara@...> 2001/12/19

原です。

[#33014] "Walrus" on LinuxJapan — Taku Nakajima <tnakajima@...>

中島@ブレーンです。

13 messages 2001/12/24

[#33050] cgi.rb で cookie の encoding について — Beyond <beyond@...>

74 messages 2001/12/28
[#33054] Re: cgi.rb で cookie の encoding について — "U.Nakamura" <usa@...> 2001/12/28

こんにちは、なかむら(う)です。

[#33057] Re: cgi.rb で cookie の encoding について — Beyond <beyond@...> 2001/12/28

[#33059] Re: cgi.rb で cookie の encoding について — nobu.nakada@... 2001/12/28

なかだです。

[#33060] Re: cgi.rb で cookie の encoding について — Beyond <beyond@...> 2001/12/28

[#33063] Re: cgi.rb で cookie の encoding について — nobu.nakada@... 2001/12/28

なかだです。

[#33065] Re: cgi.rb で cookie の encoding について — Beyond <beyond@...> 2001/12/28

[#33062] Re: cgi.rb で cookie の encoding について — Wakou Aoyama <wakou@...> 2001/12/28

青山です。

[#33075] Re: cgi.rb で cookie の encoding について — Takahiro Kambe <taca@...> 2001/12/28

In message <20011228054515.726.qmail@localhost>

[#33078] Re: cgi.rb で cookie の encoding について — Beyond <beyond@...> 2001/12/28

[#33083] Re: cgi.rb で cookie の encoding について — Wakou Aoyama <wakou@...> 2001/12/28

青山です。

[#33090] Re: cgi.rb で cookie の encoding について — Beyond <beyond@...> 2001/12/28

[#33105] Re: cgi.rb で cookie の encoding について — Wakou Aoyama <wakou@...> 2001/12/29

青山です。

[#33120] Re: cgi.rb で cookie の encoding について — Tanaka Akira <akr@...17n.org> 2001/12/30

In article <20011229013722.1869.qmail@localhost>,

[#33124] Re: cgi.rb で cookie の encoding について — Wakou Aoyama <wakou@...> 2001/12/30

青山です。

[#33131] Re: cgi.rb で cookie の encoding について — Beyond <beyond@...> 2001/12/31

[ruby-list:32866] Re: newdate

From: tadf@...
Date: 2001-12-10 09:49:01 UTC
List: ruby-list #32866
ふなばです。

At 2001-12-10T18:11:39+0900 (2452253.88309JD),
akr@m17n.org (Tanaka Akira) wrote:

> > それで、暦週というのは、一応、暦といわれますが、実際は、グレゴリオ暦の
> > ちょっと変った表記法といったものだと思うのです。Date において、ユリウ
> > ス暦とグレゴリオ暦の両方において、暦週をつかうとわけがわからなくなるの
> > で、グレゴリオ暦のみに限定することにして、グレゴリオ暦のつかわれ始めた
> > 日をデフォルトにしました。
> 
> ふむ。とすると改暦のデフォルトは GREGORIAN にすべき?

そういう考えもあると思います。

> hash はばらけるほうが望ましいわけですが、私ならばらけることの責任をほ
> かのコードに押しつけます。まぁ、ばらけなくても速度が落ちる以上の問題は
> ないわけですが。

そうですね。考えてみます。

> > > * DateTime.now は夏時間の境で問題が出るんじゃないでしょうか。
> > > 
> > >     i = Time.now
> > >     a = i.to_a[0..5].reverse
> > >     if a[-1] == 60 then a[-1] -= 1 end
> > >     d = Time.gm(*a).to_i - Time.local(*a).to_i
> > > 
> > > Time.local(*a) というのはとり得る値がふたつあることがあるので危険です。
> > > i.to_i とするほうがいいと思います。
> > 
> > えと、i.to_i とする、とはどうことですか?
> 
> Time.local(*a).to_i を i.to_i にするということです。
> 
> i = Time.now
> d = Time.gm(*i.to_a).to_i - i.to_i
> 
> 年月日時分秒に分解して元に戻すのは round trip するとは限らないので、や
> らないに越したことはありません。
> 
> なお、そうすると a[-1] をデクリメントすることができなくなりますが、そ
> れをしてもあまり正確さはあがらないのであまり問題はないかとおもいます。
> なんでかというと、デクリメントによって地方時を閏秒の挿入される前の時刻
> にするわけですが、その年月日時分秒を UTC によって解釈した時刻は時差に
> よっては閏秒の挿入後の時刻になることもあるわけです。その場合、閏秒の後
> の時刻と前の時刻の差を求めることになるので、おそらく求める値とは 1秒ず
> れます。
> 
> これを防ぐには i と i.dup.utc を Unix Epoch からの秒数ではなく、年月日
> 時分秒の表現で引き算をするのが正しいやりかただと思います。
> 
> が、しかし、そうしたとしても、tzcode では UTC と地方時で閏秒情報が異な
> る可能性があり、その場合には求める値が得られません。そこで... time.rb
> は邪悪な仮定をおき、Time.utc を使わずに求めています。
> 
> あとはどこまで考えるか、という話になりますか。

ちょっと考えてみます。

> > 負の場合は、それは日付と同じく、-1 で、23時をあらわすことができる、と
> > いう仕様にしたからです。あまり意味がないかもしれませんが。
> > 
> > 29 というのはわざとです。まず、ISO 8601 で、24時という表現を許している
> > こと、25時等の表現も便利かもしれないと思ったからです。でも、どこまで許
> > すべきなのかは、僕もよく判りません。なんとなく、29 です。
> 
> うぅむ。それは読みとれませんでした。
> 
> でも -1 で上位の年月日が変わらないのは奇妙な印象を受けます。
> 個人的には hour を -1 にした時はやはり前日という感じがします。

んー、そうですか。もうちょっと考えてみましょう。

> > > * 意図的かどうかは判断がつかないんですが militaly zone が RFC 822 の間
> > >   違いのままになっています。
> > 
> > これは何のことをいってますか?
> 
> RFC 1123 や RFC 2822 で述べられていますが、RFC 822 の 
> 
>                  /  1ALPHA                       ; Military: Z = UT;
>                                                  ;  A:-1; (J not used)
>                                                  ;  M:-12; N:+1; Y:+12
> 
> という記述は間違いです。符号がひっくり返ってます。
> 
> RFC 1123:
>          The military time zones are specified incorrectly in RFC-822:
>          they count the wrong way from UT (the signs are reversed).  As
>          a result, military time zones in RFC-822 headers carry no
>          information.
> 
> というわけで date/format.rb の
> 
>     'a'   => -1*3600, 'b'   => -2*3600, 'c'   => -3*3600, 'd'   => -4*3600,
>     'e'   => -5*3600, 'f'   => -6*3600, 'g'   => -7*3600, 'h'   => -8*3600,
>     'i'   => -9*3600, 'k'   =>-10*3600, 'l'   =>-11*3600, 'm'   =>-12*3600,
>     'n'   =>  1*3600, 'o'   =>  2*3600, 'p'   =>  3*3600, 'q'   =>  4*3600,
>     'r'   =>  5*3600, 's'   =>  6*3600, 't'   =>  7*3600, 'u'   =>  8*3600,
>     'v'   =>  9*3600, 'w'   => 10*3600, 'x'   => 11*3600, 'y'   => 12*3600,
> 
> というのは RFC 822 の間違った符号のままであることをいっています。

あー、なんか聞いたような。確認します。ありがとうございます。

ふなばただよし

In This Thread