[#29374] nil.to_s — Shugo Maeda <shugo@...>

前田です。

59 messages 2006/09/01
[#29375] Re: nil.to_s — "U.Nakamura" <usa@...> 2006/09/01

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

[#29380] Re: nil.to_s — Yukihiro Matsumoto <matz@...> 2006/09/01

まつもと ゆきひろです

[#29387] Re: nil.to_s — Shugo Maeda <shugo@...> 2006/09/01

前田です。

[#29390] Re: nil.to_s — Yukihiro Matsumoto <matz@...> 2006/09/01

まつもと ゆきひろです

[#29398] Re: nil.to_s — "NARUSE, Yui" <naruse@...> 2006/09/01

成瀬です。

[#29400] Re: nil.to_s — Yukihiro Matsumoto <matz@...> 2006/09/01

まつもと ゆきひろです

[#29491] symbol and string — Tanaka Akira <akr@...>

open-uri で :proxy=>nil という指定を行うと、以下のようにエラーになります。

33 messages 2006/09/05
[#29499] Re: symbol and string — Yukihiro Matsumoto <matz@...> 2006/09/05

まつもと ゆきひろです

[#29500] Re: symbol and string — Tanaka Akira <akr@...> 2006/09/05

In article <1157470154.047826.13379.nullmailer@x31.priv.netlab.jp>,

[#29503] Re: symbol and string — Yukihiro Matsumoto <matz@...> 2006/09/06

まつもと ゆきひろです

[#29504] Re: symbol and string — Tanaka Akira <akr@...> 2006/09/06

In article <1157505538.340126.8472.nullmailer@x31.priv.netlab.jp>,

[#29507] Re: symbol and string — Yukihiro Matsumoto <matz@...> 2006/09/06

まつもと ゆきひろです

[#29512] Re: symbol and string — keiju@... (石塚圭樹) 2006/09/06

けいじゅ@いしつかです.

[#29529] Re: symbol and string — SASADA Koichi <ko1@...> 2006/09/08

 ささだです。

[#29530] Re: symbol and string — Yukihiro Matsumoto <matz@...> 2006/09/08

まつもと ゆきひろです

[ruby-dev:29438] Re: Time#rfc2822

From: "NARUSE, Yui" <naruse@...>
Date: 2006-09-03 11:24:38 UTC
List: ruby-dev #29438
成瀬です。

Tanaka Akira wrote:
>> UTC に偽装している不明の地方時という意味があるのかと思いました。どうし
>> てかというと、
> 
> ふむ。
> 
>>>   The 1 character military time zones were defined in a non-standard
>>>   way in [RFC822] and are therefore unpredictable in their meaning.
>>>   The original definitions of the military zones "A" through "I" are
>>>   equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
>>>   are equivalent to  "+1000", "+1100", and "+1200" respectively; "N"
>>>   through "Y" are equivalent to "-0100" through "-1200" respectively;
>>>   and "Z" is equivalent to "+0000".  However, because of the error in
>>>   [RFC822], they SHOULD all be considered equivalent to "-0000" unless
>>>   there is out-of-band information confirming their meaning.
>> これをみると -0000 は信頼に足る情報が存在しない場合の便宜的な印にすぎ
>> ないように思うからです。
> 
> これはエラー処理でしかたなくそうする、という話だと私は感じま
> す。
> 
> -0000 自体の意味は、+0000 の説明と並んでいる説明が基本的な意
> 味だと私は思っています。

知らなかったのですが、RFC3339 なんてあるのですね。
で、RFC3339に同旨と思われる記述がありました。

> 4.3. Unknown Local Offset Convention
> 
>    If the time in UTC is known, but the offset to local time is unknown,
>    this can be represented with an offset of "-00:00".  This differs
>    semantically from an offset of "Z" or "+00:00", which imply that UTC
>    is the preferred reference point for the specified time.  RFC2822
>    [IMAIL-UPDATE] describes a similar convention for email.

というわけで、ある時刻の正確なUTC表記はわかるが、
地方時がわからない場合の記述なようです。


-- 
NARUSE, Yui  <naruse@airemix.com>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA

In This Thread