Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp
Aichi University
Kurozasa 370, Miyoshi-cho
Aichi, Japan
http://ar.aichi-u.ac.jp

2001/06/01 改訂

時刻合わせ

スタンドアロンシステム

	term% cd /adm/timezone
	term% cp Japan local

しかしながら、スタンドアロンのPCが他のOSと共存している場合には問題が発生する。 例えばWindow95ではMSDOSの時刻はローカルタイムである。このような場合にはPlan9側で工夫をすることができる。

	term% cat local
	JST 32400 JST 32400

	JST 0 JST 0

分散システム

• 時刻 A : システムクロック
  これはBIOSの時刻である。
• 時刻 B: 隠れた時刻
  この時刻を表示するコマンドは存在しない。 ファイルサーバが立ち上がった時点では A=B になっている。 ファイルサーバでのコマンド date によって B を変更できる。ただし A には影響しない。
• 時刻 C : ファイルサーバの時刻
  ファイルサーバのコンソールから date コマンドで表示される時刻
  なぜか C = B - 14400 となっている。つまり時刻 B より4時間遅れている。 dumpfs は時刻Cの5時(早朝)にバックアップをとる。
• 時刻 D : CPUサーバあるいは端末の時刻
  CPUあるいは端末で dateコマンドで表示される時刻である。
  この時刻はCPUあるいは端末のブート時に時刻Bと /adm/timezone/local を基に決定される。日本であれば D = B + 32400 である。つまり時刻 B より 9 時間早い。 "ls -l" コマンドで表示されるファイルの作成/改訂時刻はこれに基づく。 また /sys/log/ のファイルもこの時刻を採用している。
  注釈: 筆者は以前にForsyth の ykhttpd は GMT を採用していると書いたがサーバの 設定ミスであった。(環境変数に timezone を入れていなかった)。
  

Plan9 の時刻合わせの問題はファイルサーバの隠れた変数(時刻B)を抜きに理解できない。なぜファイルサーバの時刻が変なのであろうか?
ファイルサーバは/adm/timezone/localを見ていないのである。そのもとで早朝5時にバックアップをとるために極めて安直な「解決法」が採られたと推定できる。即ち特定の地域に合わせてファイルサーバの時刻が決定されるようにパッチが充てられたのだろう。

問題は以下のように解決すべきであろう。

• 解決策1: ファイルサーバの時刻 C を時刻 B と/adm/timezone/localによって決定する。
• 解決策2: plan9.ini に環境変数 localtime を追加し、ファイルサーバの時刻 C を時刻 B とこの変数によって決定する。
• 解決策3: ファイルサーバの時刻 C を時刻 B に一致させ、ファイルをダンプする時刻を設定するコマンドを追加する。(あるいはファイルサーバの plan9.ini で環境変数を渡せるなら、その中でダンプ時刻を指定するのもよい)

筆者はとりあえず(安易なやり方で)日本に合わせてファイルサーバの時刻が決定されるようにパッチをあてた。即ち、 /sys/src/fs/port/time.c を以下のように変更した。

変更前:
static struct
{
        short   minuteswest;    /* minutes west of Greenwich */
        short   dsttime;        /* dst correction */
} timezone =
{
        5*60, 1
};

変更後:
static struct
{
        short   minuteswest;    /* minutes west of Greenwich */
        short   dsttime;        /* dst correction */
} timezone =
{
        -9*60, 0
};

こうして変更した 9pcfs をファイルシステムのブートフロッピーにコピーする。
さて、これをブートするとびっくりする事が起きた。
ファイルシステムの整合性が取れないと言って異常終了するのだ!!
うーむ、確かに... 時間に関して以前のシステムと整合性がとれなくなっている!
筆者のは pseudo-WORM なのだから...
そこで納得して、config で

recover main

さて以上のパッチをあてると以下のようになる。 1. ファイルサーバの時刻 A をグリニッジ標準時に合わせる。即ち日本時間より9時間遅らせる。 2. するとファイルサーバの時刻 C は A より9時間あるいは8時間進んでいる。 日本時間と等しくない事があるが気にしなくてもよい。1時間の違いが発生する事があるのは、アメリカの夏時間が想定されているからである。 3. 以上によって CPU サーバと端末の時刻は A による設定から 9 時間すすみ、日本時間に合っている。

日本でもサマータイム制度を勧める議論があるが、反対しましょう。このような制度を導入すると OS に複雑極まるパッチを当てなくてはならなくなります。誰が得をして誰が損をするかは明らかです。夏になったら早く出社すべきであると考えるのは各社の自由ですが他人に強制せずに単に出勤時間を各社の判断で変更すればよいだけです。