ソフトウェア > Lotus > Lotus Developer Domain >

Iris Today Archives

正確に時を刻む：ノーツはタイム・ゾーンやサマー・タイムをどのように扱っているか

by Dave Delay
レベル：中級者
対　象：すべて
原文の掲載：2001年3月1日

Iris Today Archivesの原文

インデックス

	ノーツ 4.x のタイム・ゾーン・サポート
	R5 におけるタイム・ゾーン機能の改良点
	R5 をタイム・ゾーン間を移動して使用する
	MacOS での重要点について
	タイム・ゾーンに関するトラブル・シューティング
	カレンダーやスケジュール機能における問題点
	まとめ

これは「時間」についての記事です。正確に表現するならば、「ノーツがどのようにタイム・ゾーンやサマー・タイムを扱っているか」についてご紹介したいと思います。

今の時期は世界中の多くの地域でサマー・タイムが始まったり、逆に終わったりしているので、タイムリーな話でもありますが、タイム・ゾーン間の時間の変換で生じる問題は、このサマー・タイムが始まったり終わったりしてからの数週間にまず現れます。

この記事ではまず、どのようにノーツ 4.x や R5 がタイム・ゾーンを扱っているかを説明します。これで、タイム・ゾーンに起因する問題が生じたときに御自身で解決ができるようになります。

次に、ノーツ R5 に搭載された改良型のタイム・ゾーン・サポートでは、オフィスで作業をしていても、海外を旅していても、現在ユーザーがいる場所にタイム・ゾーンやサマー・タイムの設定を変更することがいままで以上に簡単になっており、このことについても紹介します。

最後に、タイム・ゾーンに関してよく見られる問題を解決するためにR5.0.2、R5.0.3 のカレンダーやスケジュール機能に加えられた変更点についても紹介します。

ノーツ 4.x のタイム・ゾーン・サポート

ノーツでは、時間を表すための多目的データ型として、Time/Date フィールドが使われています。その名前からも分かるように、Time/Date フィールドは時間と日付の値をセットで保持することができます。また、用途によってはそのどちらかのみを保持することも可能です。例えば、終日のイベントの内容を記述した文書を作成する場合、時間を特定することなく日付のみを保存することができます。これは、Time/Date フィールドの重要な特長の1つですが、分かりやすくするために、この記事では時間と日付の両方がフィールドに含まれているものとします。

Time/Date フィールドのディスク上での記録フォーマットはマニュアルで明らかにされてはいませんが、フィールドのデータは、実際は2つの 32 ビット文字列に分けられます。そのうちの1つは、午前0時から 0.01 秒がカウントされた回数を整数で保持し、もう1つはユリウス暦形式で表した日付を整数で保持します。この方法でノーツは紀元前 4713 年から、はるか先の未来までの日付を表すことができます。(残念ながら紀元前5世紀の「マイナス Y5K」には対応していませんが)

この Time/Date フィールドの中で重要なのは時間を保持する部分です。先ほど述べたとおり、午前0時から 0.01 秒がカウントされた回数を保持しますが、いったいどのタイム・ゾーンでそれを行うのでしょうか。実は、ノーツはグリニッジ標準時 (GMT) を基準にして時間を保管しています。この考え方に基いた設計は、数多くあるノーツの基本機能を動作させる上で非常に重要なものとなっています。例えば、すべての時間が GMT を基準にしているために、インデクサーは、時間順の並び替えを単純な整数比較で行うことができます。もし時間がそれぞれのタイム・ゾーンを基準にして保管されていたなら、2つの時間や日付の値を比較する前のタイム・ゾーンの変換作業で、インデクサーが混乱してしまうでしょう。

グリニッジ標準時での時間の値を保管するために、ノーツはローカル・タイム・ゾーン (大抵の場合、現在設定されているタイム・ゾーンのことです) の値から変換します。この変換はノーツ・クライアントの設定をもとにして行われます。この際に次のような決まりがあります。

ローカル・タイム・ゾーンから GMT への変換はノーツの設定が正しくなければうまく行われません。実際に、タイム・ゾーンに関する問題の99パーセントはノーツ・クライアントの設定が正しくないことによります。
もちろん、ノーツのアプリケーションのほとんどは GMT の時間を表示をするわけではなく、GMT をあなたが現在いる地域の時間に変換してから表示します。ですから当然、ノーツはこの際もローカル・タイムから GMT に変換したときに使った設定を使うことになります。
ノーツ・クライアントを1つしか使用していないときには、タイム・ゾーンに関する問題が存在するのかどうか分かりにくい場合があります。しかしノーツ・クライアントが複数あるとき、特にそれぞれのクライアントが異なったタイム・ゾーンに設定されている場合には問題が明らかになります。ですから、ノーツ・クライアントを展開するときには、重要ではないと思えても複数のタイム・ゾーンに設定して、それぞれをテストする必要があります。

タイム・ゾーンを指定する
ノーツ 4.x を最初に起動するときには、ドミノサーバーに接続するために必要な情報を入力します。このときに、接続の種類や ID ファイルの所在、ホーム・サーバーの名前を入力し、下図のダイアログ・ボックスであなたの地域のタイム・ゾーンを選択します。

Time Zone Setup

ここではノーツで定義されたリストからタイム・ゾーンを選びます。アメリカ英語版のノーツに含まれているタイム・ゾーン一覧はノーツのタイム・ゾーンを参照してください。

初めてタイム・ゾーンを選択すると、すべてのロケーション文書にその設定が適用されます。ホーム、オフィス、そしてアイランドのロケーションには選択したタイム・ゾーンが設定されるわけですが、ノーツはモバイル面で優れたクライアントであるため、それぞれのロケーション文書に異なるタイム・ゾーンを設定することが可能です。

例えば、オフィスのロケーションを東部標準時 [EST] に設定して、旅行するときは「ホテル」というロケーションを使う、といったこともできます。シカゴに1週間出張に行くことになったときなどは、「ホテル」のロケーションに変更し、 [ファイル] - [モバイル] - [現在の時間と電話番号] を選択します。すると下の図が表示されます。

Time and phone information for hotel

このダイアログ・ボックス上で中部標準時 [CST] を選択しても、ホテルのロケーションにしか効果を及ぼしません。ですから、出張からオフィスに帰ってきたときにロケーションをオフィスに戻すと、ノーツはあなたが東部標準時間帯に戻ってきたということを認識します。

サマー・タイムの対策
ノーツのタイム・ゾーンのタイム・ゾーンのリストはどのように世界が分割されているかを知るためのとても良い例だと言えます。地球上を東から西へと移動していくと、経度15 度ごとに1つのタイム・ゾーンがあり、それぞれのタイム・ゾーンは東に隣接するゾーンよりも1時間遅れであることがわかります。また、GMT と何時間差というタイム・ゾーンだけでなく、何時間何分差というものもありますが、これよりももっとやっかいな問題があります。

タイム・ゾーン間の変換で最もやっかいな問題とは、サマー・タイムなのです。ほとんどのタイム・ゾーンは多数の国の管轄下にあるため、サマー・タイムを実施している部分とそうではない部分がでてきます。前者の国の人たちは暖かい季節になると時計を1時間早めます。北半球では、4月から 10 月までがサマー・タイム、南半球では 10 月から4月がサマー・タイムという場合がほとんどですが、正確な日付はその地域の行政が決めることなので、地域によって大きな違いが生じてしまいます。

GMT から西へ5時間のタイム・ゾーンを考えてみてください。この地域はカナダの東部とアメリカの東部、そしてコロンビアやエクアドル、ペルーといった南アメリカ西部の国々を含んでいます。このうち、カナダとアメリカのほとんどの部分では毎年4月から 10 月にかけてサマー・タイムを実施していますが、インディアナ州のいくつかの郡では実施しておらず、コロンビア、エクアドルやペルーにいたってはまったく実施されていません。どうすればこのように異なった地域にノーツ 4.x を正しく設定できるのでしょうか。

サマー・タイムが実施されていない場合
もしあなたが南アメリカ西部やインディアナのサマー・タイムを実施していない郡でノーツを使っているとすれば、東部標準時 [EST] をタイム・ゾーンに選択し、 [サマー・タイムの実施] のチェックをはずさなければなりません。

Time Zone Setup

Time/Date の値を入力すると、ノーツはそのデータの日付部分は無視して、ローカル・タイムに常に5時間を加えることによって GMT を計算するようになります。

サマー・タイムが実施されている場合
もしあなたがカナダ東部やアメリカ東部のサマー・タイムを実施している地域でノーツを使っている場合はもうすこし複雑になります。この場合はタイム・ゾーンを東部標準時 (EST) にし、 [サマー・タイムの実施] をチェックして、ノーツがサマー・タイムを考慮した上で GMT に変換するようにしなければなりません。

この状態で Time/Date の値を入力すると、ノーツは正しくローカル・タイムから GMT へ変換します。Time/Date フィールドの日付の値がサマー・タイム実施期間外のときはローカル・タイムに5時間を足して、またサマー・タイム実施期間中のときは4時間を足して GMT を計算します。

サマー・タイムは実施されているが、開始日や終了日が標準ではない場合
もしあなたが、サマー・タイムは実施してはいるが、その開始と終了の日付がノーツにプリセットされている日付と異なる地域でノーツを使っている場合は、NOTES.INI ファイル中の DSTLAW の設定を変更するというステップを踏む必要があります。

アメリカ英語版のノーツは、サマー・タイムは4月の第1日曜日から 10 月の最後の日曜日まで、という前提で作られており、実際にアメリカやカナダのサマー・タイムを実施している地域ではすべてこの日付で実施されているため、ほとんどのユーザーは NOTES.INI ファイルの設定を変更する必要はありません。

インターナショナル英語版(北米以外の地域向けで、これに翻訳などを施し各国語版となるものです。)のノーツでは、サマー・タイムは3月の最後の日曜日から 10 月の最後の日曜日までという前提がなされており、これはサマー・タイムを実施しているほとんどのヨーロッパ諸国に沿った設定です。

このなかでおもしろい例外はフランスです。フランスでは毎年サマー・タイムの開始と終了の日付を制定するのです。こうした例外があるものの、一般的には各地域で販売されているノーツはその地域にあった DSTLAW プリセットを持っており、必要なときにのみ以外は編集する必要はありません。

サマー・タイムの開始と終了の日付を変更するには、NOTES.INI の DSTLAW の設定を編集します。DSTLAW の書式は次のようになります。

DSTLAW=startmonth startweek startday endmonth endweek endday

*DSTLAW の設定*
書式	説明
startmonth	サマー・タイムが始まる月
startweek	サマー・タイムが始まる週。その月の第1週なら1、最後の週なら-1
startday	サマー・タイムが始まる日付。日曜日なら1
endmonth	サマー・タイムが終わる月
endweek	サマー・タイムが終わる週。その月の第1週なら1、最後の週なら-1
endday	サマー・タイムが終わる日付。日曜日なら1

例えば、次の例はサマー・タイムが4月の第1日曜日に始まって、10月の最後の日曜日に終わることを示します。

DSTLAW=4 1 1 10 -1 1

また、次の例はサマー・タイムが3月の最後の日曜日に始まって、10月の最後の日曜日に終わることを示します。

DSTLAW=3 -1 1 10 -1 1

上に戻る

R5 におけるタイム・ゾーン機能の改良点

ノーツ R5 のタイム・ゾーン機能の改良点は、一言で表すと、「OS との統合」と言えます。

ノーツ R5 は OS のタイム・ゾーン、サマー・タイムの設定を調べ、それらを利用します。Windows 95、98、NT、そして 2000 といったマイクロソフトの 32 ビットの OS シリーズではその機能が有効です。Macintosh 版のノーツ R5 では MacOS の 8.6 以降であれば同様に有効です。混乱を避けるために、ここからは Windows を使用した場合からの説明を行います。Macintosh 上で R5 がどのようにタイム・ゾーン機能を扱うかについてはこちらをご覧下さい。

Windows 上で始めてノーツを起動するとき、新しいクライアントの設定の際にタイム・ゾーンを選択する必要がなくなっていることに気付くかもしれません。ノーツはそのかわりに OS の日付の設定が正しいと仮定します。この動作は R4.x と比べ大した違いには見えないかもしれませんが、4.x のタイム・ゾーン設定が OS からは独立していたことに対し、R5 では依存している、という意味で非常に重要なポイントです。

言いかえれば、4.x では正しいタイム・ゾーンの情報を得るのにノーツ自身の設定を参照していて、OS の日付と時刻の設定は重要ではなかったのに対し、R5 では OS の日付と時刻を参照するため、それらが正しく設定されているということが非常に重要になってくる、ということです。ですから、ノーツ R5 をインストール際には OS の日付と時刻の設定をコントロール・パネルからチェックして、タイム・ゾーン正しく設定されていることを確認するのが良いでしょう。

例えば、Windows NT 4.0 の [日付と時刻のプロパティー] ダイアログ・ボックスは次のようになります。

Windows date/Time properties

上図は、カナダ東部とアメリカ東部のほとんどの地域での正しい設定です。もしこの地域の中で、サマー・タイムが実施されている地域に住んでいて、ノーツ 4.6 を毎日使っているなら、 [自動的に夏時間の調整をする] をチェックしてもしなくても関係ありません。ノーツ 4.6 内の [タイム・ゾーンの設定] ダイアログ・ボックスの [サマー・タイムを実施する] がチェックされていれば、ノーツ 4.6 はサマー・タイムを正しく処理できます。しかし、R5 を使っているなら、 [日付と時刻のプロパティー] ダイアログ・ボックスの [自動的に夏時間の調整をする] をチェックすることが必要で、もしチェックしなければノーツはサマー・タイムに合わせて時間を調節することができません。

同様に、もしインディアナのサマー・タイムを実施していない地域に住んでいて、ノーツ 4.6 を毎日使っていても、 [自動的に夏時間の調整をする] をチェックするかしないかは関係ありません。ノーツ 4.6 の [タイム・ゾーンの設定] ダイアログ・ボックスの [サマー・タイムを実施する] のチェックがはずれていれば、ノーツはサマー・タイムを考慮しません。しかし、R5 では [日付と時刻のプロパティー] ダイアログ・ボックスの [自動的に夏時間の調整をする] のチェックをはずすことが必要です。もっとも、リストの中から [インディアナ東部] を選択する方が賢明と言えますが。

Indiana

上に戻る

R5 をタイム・ゾーン間を移動して使用する

OS のタイム・ゾーン設定を使うことによって、ノーツ R5 を持って移動することが今まで以上に簡単になります。初期設定ではすべてのロケーションが OS の時間を使うことになっているので、違うタイム・ゾーンにある地域に移動するときには、OS の設定を変更するだけで、同時にノーツも新しいタイム・ゾーンに設定され、とても簡単です。

しかし、ノーツ 4.x のロケーションのタイム・ゾーン変更方法に慣れていて、その方式で設定したい、という方にも朗報です。ノーツ R5 でもこの方式はサポートされています。

例えば、オフィスのロケーションを東部標準時 [EST] に設定し、旅行するときはホテルというロケーションを使います。シカゴに１週間滞在するなどというときには、ロケーションをホテルにして、 [ファイル - モバイル - 時間と電話番号] を選択します。すると下図のようなダイアログ・ボックスが表示されます。

Time and phone information for hotel

R5 と 4.x で [インターネットの時間と電話の情報] ダイアログ・ボックスの外見がやや異なっていますが、できることは同じです。 [タイム・ゾーン] を中部標準時に設定すれば、ホテルのロケーションにのみ反映されます。これはノーツ 4.x でもほぼ同じですが、以下の点に注意してください。

[インターネットの時間と電話の情報] ダイアログ・ボックスを使って中部標準時に設定すると、ノーツ R5では OS のタイム・ゾーンも中部標準時に設定が変更されます。そのあとにロケーションをオフィスに戻しても、ノーツが OS のタイム・ゾーンを中部標準時に設定したままでもとに戻さない場合がありますが、これはオフィスのロケーションがどのように設定されているかによります。もし下図のように設定されていれば、OS のタイム・ゾーンは中部標準時のままになります。
この問題を解決するには、 [OS の標準時設定を使用] を [いいえ] にします。すると [標準時] というフィールドが現れるので、オフィスのロケーションがあるタイム・ゾーンを設定します。こうすることによって、他のロケーションからオフィスに戻すたびに、OS のタイム・ゾーン設定はオフィスのロケーション文書で設定されたものと同じになります。
[ファイル] - [モバイル] - [時間と電話番号] を選択したときに、 [タイム・ゾーン] が変更不可能になっている場合があります。

これもロケーション文書に関係があります。ノーツは [OS の標準時設定を使用]が[はい] になっているロケーションは [タイム・ゾーン] を変更不可能にします。このダイアログ・ボックスでタイム・ゾーンを設定したい場合は、ロケーション文書の中で [OS の標準時設定を使用] を [いいえ] にしてください。

OS と統合することのメリット
OS と統合するメリットはまず、OS とノーツのタイム・ゾーンやサマー・タイムの設定が1度で済むということがありますが、これ以外にも小さなメリットがいくつかあります。

まず、タイム・ゾーン間の移動が非常に容易になります。ノーツ 4.6 ではタイム・ゾーン間を移動する際には、ロケーション文書でタイム・ゾーンの設定を変更する必要がありましたが、ノーツ R5 では Windows のコントロール・パネルで設定を変更するだけでよくなっています。ロケーション文書で [OS の標準時設定を使用] が [はい] になっていれば、ノーツのタイム・ゾーンの設定は全く気にする必要はありません。
Windows のタイム・ゾーンの名前は、ノーツ 4.x よりも詳しく記述されています。例えば Windows NT では、GMT から西に5時間のタイム・ゾーンは3つ挙げられています。

(GMT-5:00) 東部標準時 (米国およびカナダ)
(GMT-5:00) ボゴタ、リマ、キト
(GMT-5:00) インディアナ東部

これによって、どのタイム・ゾーンを選択すればよいかが分かりやすくなっています。コロンビアに滞在しているのであれば、コロンビアはアメリカ東海岸とほぼ同じ経度に位置していて、夏時間を実施していない、ということを知らなくても、ただ [ボゴタ、リマ、キト] を選択すればいいのです。
Windows のタイム・ゾーンでは、サマー・タイムの始まりと終わりの日付が考慮されています。もしイギリスに滞在しているなら、 [グリニッジ標準時] に設定すれば、ノーツ R5 でも正しいサマー・タイムの始まりと終わりの日付が設定されます。例えば、イギリスではアメリカよりも1週間早くサマー・タイムに移行する、ということを知らなくてもよいのです。しかしなによりも、4.x と違って NOTES.INI の DSTLAW の設定を変更する必要がない、という利点があります。

上に戻る

MacOS での重要点について

Macintosh 上でノーツ R5 を使う場合、ノーツが OS の標準時設定を統合する際に、いくつかの違いに注意してください。

MacOS 8.5 以前では、ノーツは OS の標準時設定を認識することが出来ません。これらの旧バージョン上では、ノーツ R5 はノーツ R4.x の場合と同様にタイム・ゾーンを設定します。
MacOS 8.6 以降では、[OS の標準時設定を使用] を [はい] に設定した時、サマー・タイムを実地していなかったとしても、ノーツは GMT から差し引いた現時点でのタイム・ゾーンを認識することができます。ノーツは MacOS からのサマー・タイムの開始と終りの日付を認識することができません。Macintosh 上では、ノーツは依然としてとして NOTES.INI に設定されている DSTLAW 設定を使用しています。先に述べたように、ほとんどのユーザーは DSTLAW の編集をする必要がありません。DSTLAW の編集が本当に必要となった場合にはこちらをご覧下さい。
[OS の標準時設定を使用] を [いいえ] と設定する場合、ノーツはタイム・ゾーンの一覧から選択させます。Windows 上では、ノーツはこのタイム・ゾーンの一覧を Windows レジストリーから取り出します。MacOS 8.6 以降では、ノーツはタイム・ゾーンの一覧を OS 上から取り出すことができません。そのため、ノーツ 4.x ような表が表示されます。（ノーツのタイム・ゾーンを参照）この中にあるタイム・ゾーン一覧は、サマー・タイムの開始と終りの日付を含んでいません。例えばオーストラリアのメルボルンから米国のボストンに移動したとき、場所の切り替えをするだけではいけないということです。メルボルンとボストンは異なるサマー・タイムの開始と終りの日付のため、DSTLAW の編集をする必要があります。

上に戻る

タイム・ゾーンに関するトラブル・シューティング

今までタイム・ゾーンに関する理論について説明してきたので、それを実際に使ってみましょう。ここでは、よくあるタイム・ゾーンに関するトラブルと、その解決方法を紹介します。ノーツ 4.x と R5 ではタイム・ゾーンの扱いが違うので、解決方法がそれぞれ少し異なっています。

よくあるトラブル
Aさんがシアトルに本拠地を置く大企業で働いているとしましょう。シアトルでは太平洋標準時間帯 [EST] の中にあり、サマー・タイムが実施されています。Aさんは、毎週マネージャーと報告会を行うことになっており、2000 年4月の第1週に、マネージャーから4月6日の報告会に出るように、というメールが届きました。メールのタイトルが「報告会 (4月6日 PM 2：00 EST) 」とあったので、「毎週恒例の報告会だな」と、Aさんは気にも留めずにカレンダーを開いてスケジュールに登録してしまいます。

さて、4月6日。Aさんが仕事をしていると、ノーツのアラームダイアログ・ボックスが開いて、報告会が午後3時からある、と知らせます。報告会は3時からではなくて確か2時からだったはずだ、と思い、カレンダーを開いて調べてみますが、カレンダーでも3時になっています。Aさんは「2時というのは自分の思いこみだろう」と、報告会の開かれる場所に3時ちょっと前に行きます。するといくら待ってもマネージャーは来ません。おかしいと思って電話してみると、マネージャーは2時に来ていて、Aさんを待っていたというではありませんか！

もうこの問題はサマー・タイムのせいだということがお分かりでしょう。アメリカでは4月の第1日曜日に時計を1時間早めます。この例では、Aさんかマネージャーのどちらかが設定を誤り、ノーツ・クライアントのサマー・タイムへの移行が行われませんでした。では、どちらが設定を誤ったのかというと、Aさんにはかわいそうですが、実はマネージャーなのです。報告会の開始時間がマネージャーのカレンダーでは1時間早かったのです。

ノーツ 4.x での解決法
Aさんのマネージャーがノーツ 4.x を使っているとします。ノーツ 4.x は OS のタイム・ゾーンやサマー・タイムの設定を使用しないので、マネージャーのノーツ内のロケーション文書を設定しなおす必要があります。まず、 [ファイル] - [モバイル] - [現在の時間と電話番号] を選択し、 [サマー・タイムの実施] をチェックするという方法がありますが、もう1つ、直接ロケーション文書を編集するという方法もあります。これにはロケーション文書を編集し、 [詳細] セクションを開き、 [サマー・タイムの実施] を [しない] から [する] に変更します。

ノーツ R5 での解決法
Aさんのマネージャーがノーツ R5 を使っているなら、解決方法は少し異なります。まず、ロケーション文書を開き、マネージャーのノーツが OS のタイム・ゾーン設定を使っているのかどうかを調べます。ロケーション文書中の [詳細] タブ上にある [基本] タブをクリックします。 [OS の標準時設定を使用] が [はい] になっていれば、Windows のコントロール・パネルから [時間と日付のプロパティー] ダイアログ・ボックスを開き、 [自動的に夏時間の調整をする] をチェックします。 [OS の標準時設定を使用] が [いいえ] であれば、ロケーション文書中の [サマー・タイムの実施] を [サマー・タイムを実施する] に変更します。

上に戻る

カレンダーやスケジュール機能における問題点

ノーツに搭載されているアプリケーション C&S（カレンダ＆スケジューリング機能）は、時間と日付を扱うというその性質上、タイム・ゾーンの持つ特有の問題がよく見られるアプリケーションでもあります。ここでは、この C&S やタイム・ゾーンの問題を扱っている QMR（Quarterly Maintenance Releases: 5.0.1 や 5.0.2 など基本的に四半期毎にリリースされるアップデート版のこと）の中から、最新の情報を取り上げます。

タイム・ゾーン間をまたぐ終日のイベントの扱い
ノーツ R4.5 で C&S を導入して以来、終日のイベントをセットすると、カレンダーに予定している前の日に表示されることがある、という報告がいくつかありました。例えば、いつもはタイム・ゾーンを東部標準時に設定していて、その中で行事をカレンダーに作成します。それから西海岸に旅行することになり、タイム・ゾーンを太平洋標準時に設定しなおしました。カレンダーを開けてみると、先ほど作成した行事は、予定しているよりも1日早く表示されています。

この問題については、ノーツ/ドミノ 5.0.3 のメール (R5.0) テンプレートで解決されています。それ以前は、終日のイベントを作成するとその開始時間は午前0時1分に設定され、東部標準時から太平洋標準時に変更すると、開始時間が予定の前の日の午後9時にずれてしまい、その結果として行事が予定の前日に現れてしまいました。

そこで 5.0.3 のメール・テンプレートでは終日のイベントの開始時間を午前4時1分にしました。しかし、これでも問題が生じてしまうケースがまだあります。例えば、西に時差が4時間以上あるタイム・ゾーンに移動した場合は、終日のイベントは予定したよりも1日早くカレンダーに表示されてしまいます。しかも、この修正ではすでに作成した行事については効果がありませんので、それらについては依然として1日早く表示されたままとなってしまう問題をかかえています。現在わたしたちは、次のノーツのメジャー・リリースに向けて、より完璧な解決策を検討しています。

異なるタイム・ゾーンにいるユーザー間の空き時間情報の調整
もう1つのタイム・ゾーンに関する問題は、異なるタイム・ゾーンにいる2人のユーザーが、同一のドミノサーバーにメールのファイルを保管している場合です。例えば、山田さんが東部標準時で、田中さんが太平洋標準時で働いており、2人のメールが保管されているドミノサーバーは東部標準時間帯にあるとします。また、2人が働く時間は月曜日から金曜日までの午前9時から午後5時までです。この条件で、山田さんが田中さんと電話で打ち合わせをしようと思うと、問題が生じる場合があります。お互いに異なるタイム・ゾーンにいるので、山田さんにとっては田中さんも9時から5時まで働いているように思えても、実際は田中さんは東部時間にして正午から午後8時まで働いているのです。

ノーツ/ドミノ 5.0.2 以降のメール (R 5.0) テンプレートに、この問題を解決する機能を搭載しています。

田中さんはこの機能をいかすために、次のステップを踏む必要があります。

メール・ファイルの設計を更新します。
カレンダーを開きます。
[アクション] - [ツール] - [プリファレンス] を選択します。 [空き時間] のタブをクリックします。
再計算を行うために、空き時間に何らかの修正を加えます。例えば、スペースを1つ追加する、といったことで十分です。
[OK] をクリックして修正内容を保存します

これらのステップを踏めば、田中さんの現在のタイム・ゾーン情報、つまり太平洋標準時が田中さんの空き時間情報に保存されます。そして山田さんが田中さんの空き時間を問い合わせたときには、空き時間、予約時間の管理機能によって、ここで設定したタイム・ゾーンが使われます。ここで、山田さんはこれらのステップを踏む必要がないということに注意してください。これは山田さんが東部標準時間帯にいて、サーバーも同じタイム・ゾーンにあるので、山田さんの空き時間はすでに正しく設定されているためです。

異なるタイム・ゾーンにある会議室の空き時間の調整
異なるタイム・ゾーンにある2つの会議室の情報が1つの会議室予約データベースに保存されているときに、上と同じような問題が生じます。仮に「ボストン・ハーバー」という会議室が東部標準時間帯に、「ベイ・ビュー」という会議室が太平洋標準時間帯にあり、共に東部標準時間帯にあるドミノサーバーの会議室予約データベースに保存されているとしましょう。これでは上の例に出てきた田中さんがベイ・ビュー会議室を予約しようと思ったときに問題が生じてしまいます。ベイ・ビュー会議室の空き時間は田中さんがいる太平洋時間帯に調整されていないのです。

ノーツ/ドミノ 5.0.2 以降に含まれている会議室予約 (5.0) テンプレートでは、この問題を解決することが可能です。田中さん、あるいは田中さんと同じタイム・ゾーンにいるユーザーは次のステップを踏む必要があります。

会議室予約データベースの設計を更新します。
会議室予約データベースを開きます。
ベイ・ビュー会議室の情報を変更します。
ベイ・ビュー会議室の再計算を行うために、空き時間に何らかの変更を加えます。スペースを追加する、といったことで十分です。
会議室情報を保存します。

これでベイ・ビュー会議室の現在のタイム・ゾーン情報が、空き時間情報と共に保存されました。ここでボストン・ハーバー会議室の情報は変更しなかったということに注意してください。これは、ボストン・ハーバー会議室が会議室予約データベースと同じ東部標準時間帯にあり、空き時間情報がすでに正しいためです。

上に戻る

まとめ

この記事で、タイム・ゾーン間での変更、サマー・タイムの実施、さらにユーザーが世界中を旅行や仕事で移動するといったことへの対処について、考慮しなければならない細かな点が多くあるということをご紹介しました。この記事で取り上げたことは、これからあなたが時間に関するトラブルに対処する際に役に立つことと思います。わたしたちはこれからも、ノーツが正確に時を刻むように改良を続けていきます。

著者について
デイブ・デレイはアイリスに4年間所属し、ノーツ・クライアント・チームのプロジェクト・リーダーを務めています。彼のチームはメールやカレンダー、スケジュールといった機能を手がけています。

上に戻る