In article <E1LyTuj-0003h2-28 / x61.netlab.jp>,
  Yukihiro Matsumoto <matz / ruby-lang.org> writes:

> |Time.new(year, mon, day, hour, min, sec, utc_offset)
> |ならどうでしょうか?

> こっちには賛成です。

ではそれで。

> Timeクラスの既存の部分は、UNIXが提示していたモデル、つまり
> UTCか地方時のいずれかというモデルに強く影響を受けていますし、
> 使う人(この場合は私)もそのモデルになれきっています。既存の

そういうモデルを UNIX が提示しているというのは本当でしょうか?

UNIX が提供しているデータ構造は time_t と struct tm ですが、
これは UTC か地方時のいずれかというモデルではありません。ど
ちらにも UTC か地方時かという情報は含まれていません。

time_t から struct tm へ変換する関数として gmtime と
localtime が用意されているという点は UTC と地方時のどちらか、
という感はありますが、べつに特定のオフセットを用いて変換する
関数を用意することが難しいわけではありません。実際、gmtime
を使って struct tm を得た後、オフセットを足せばそれで実現で
きます。

また、struct tm に tm_gmtoff が定義されるようになったのは、
任意の時差を扱う布石とも考えられます。まぁ、これは標準ではあ
りませんが。

> getlocalは地方時を返すわけですが、そこで引数を渡したら、UTCで
> も(古い意味での)地方時でもないものを返すと言うのは、ちょっと
> 抵抗があります。「予想される挙動うんぬん」は勘違いによるもの
> だったので忘れてください。
>
> 要するに、新たに導入されたものがUTCでも地方時でもない「オフセッ
> トが指定された時刻」ととらえるか、地方時に「オフセット」とい
> う新しい属性が増えたととらえるか、という点なんでしょうか。田

UTC からのオフセットというのは地方時の一種である、というのが
私の考えです。たとえば、日本標準時は、+09:00 という一定のオ
フセットをもつ地方時と考えられます。また、人工的な定義が
/usr/share/zoneinfo/Etc に GMT[+-]HH という形で用意されてい
たりもします。

% ls /usr/share/zoneinfo/Etc
GMT     GMT+11  GMT+4  GMT+8  GMT-10  GMT-14  GMT-5  GMT-9      UTC
GMT+0   GMT+12  GMT+5  GMT+9  GMT-11  GMT-2   GMT-6  GMT0       Universal
GMT+1   GMT+2   GMT+6  GMT-0  GMT-12  GMT-3   GMT-7  Greenwich  Zulu
GMT+10  GMT+3   GMT+7  GMT-1  GMT-13  GMT-4   GMT-8  UCT

ですから、getlocal の引数は (固定オフセットのものに限定され
ますが) どの地方時を使用するかという指定であり、指定されてい
なかったら OS が提供している地方時を使う、というのが私の見方
です。getlocal が地方時に設定したオブジェクトを返すものだと
いう概念は変わりません。

> 中さんは後者の立場のようですが、strftimeを始めとして茨の道の
> ような気がします。time関係の関数をすべて再実装しなければなら
> ないような気がするのですが、ある程度はもう再実装してるわけだ
> し実は手間はそれほどでもないのかな。

冒頭に述べた通り、データ構造は UTC か地方時のいずれかという
モデルではありませんのでプログラムの構造自体を変えるという話
にはなりません。

ただ、struct tm は tm_gmtoff を持っていないこともあるので使
えませんが、表現範囲を広げた時点で (tm_year が overflow しな
いように) 独自の構造体を使うように変えてあるので、すでにその
へんの作業は済んでいます。たとえば、rb_strftime は struct tm
ではなく、独自の構造体を受け取る関数になっています。

そのあたりを茨の道と呼ぶなら、それはもう通り抜けてしまってい
るといっていいでしょう。
-- 
[田中 哲][たなか あきら][Tanaka Akira]