ServiceNowのタイムゾーンの初期設定

はじめに

インスタンスを初めて作るときに構成しなければいけない基本的な項目というのを、いくつか取り上げてみたいと思うのです。この辺り、体系的かつ網羅的なパラメーターシートを作っておられる方もいらっしゃるかも知れませんが、行き当たりばったりになりやすい部分でもありますので、そういう状態が不安だという方の一助になればと思うところです。

インスタンスにおける時間の扱い

ServiceNowのインスタンスが管理する内部の時間は、UTC（協定世界時）で管理されています。ただし、インスタンス上でそれを画面に出すときにはインスタンスの標準のタイムゾーンでの時刻に換算して表示しますし、ユーザーがそれと異なるタイムゾーンで利用しているときは、そのユーザーにあった時間で表示をすることになります。

つまり、内部の生データはUTCですが、インスタンスにおける標準タイムゾーンは1つ決めておくことができ、ユーザーレベルでも個別のタイムゾーンを設定できるという3段階の構えになっています。

インスタンス標準のタイムゾーンを設定する

設定の箇所

ではどこでインスタンスの標準タイムゾーンを設定できるのでしょうか。

これはアプリケーションナビゲーターから「All > System Properties > Basic Configuration」へアクセスし、そこで設定ができます。できたばかりのインスタンスでは米国ロサンゼルスの時間になっています¹。これをまずは日本時間にしましょう。

インスタンスで利用可能なタイムゾーンの選択肢を構成する

ここですぐにわかることがあります。日本標準時が選択肢にないことです。

日本標準時をインスタンスの標準に使うためにはまず「インスタンスで選択できるタイムゾーンに日本標準時を加える」という設定が必要なのです。幸いにして、この画面のすぐ横にその設定を行うリンクがあります。このリンクを押すと下の図のようなスラッシュバケットに似たUIの設定画面が表示されます。ここで、左側の選択肢から必要なもの（ここでは日本標準時）を右に持っていくと前の画面の選択肢にもそれが現れるようになります。

ちなみにこのデータがどこにあるのかというと、実は選択肢テーブルにあります。ユーザー（sys_user）テーブルの「タイムゾーン(timezone)」という選択肢フィールドの選択肢がそれで、設定画面で左から右に移したタイムゾーンはこの選択肢テーブル上の「非アクティブ（inactive）」フィールドの値がtrueからfalseに変わることによって利用可能になる仕掛けです²。

タイムゾーンのフォーマット

さて、問題は、この膨大なタイムゾーンの選択肢のうち、どれを有効にすべきなのかと言う話です。先ほど「日本標準時を加える」とは言ったのですが、日本標準時がどの選択肢であるのかは意図的にぼやかしていました。インスタンスをご覧の方はお気付きの通り、日本時間を表すタイムゾーンの選択肢も、「Asia/Tokyo」と「Japan」と「JST」の3つがあります。

結論から言うと「Asia/Tokyo」にしてください。この「JST」のような略称形式のタイムゾーンは使えますが新しいシステムに取り込むべきものではありません。略称形式のタイムゾーン名称には被りがあって、例えばCSTは中国標準時と米国の中部標準時の両方の意味があり、しかも区別が困難です。ちなみに私が試したインスタンスでCSTを設定すると米国の中部標準時になりました（America/Chigagoと同じ時刻）。

この流儀で、必要な地域を示すタイムゾーンについて、「地域名/都市名」のフォーマットのものを必要なだけ登録してください。

登録すべきタイムゾーンとは

全世界のタイムゾーンを全て登録するというのは、この選択肢を見ていただいただけでも煩雑なものになると思います³。

ではどのタイムゾーンを登録するのかというと、基準は明確でユーザーが所在する地域のタイムゾーンをすべて登録するということになります。最初の話に出てきた通り、システムの内部時刻はUTCであり、デフォルトタイムゾーンは管理者が1つに定めます。もう一つのタイムゾーンの存在意義は、ユーザーが自分のタイムゾーンでシステムを利用できるということです。タイムゾーンの選択肢が、ユーザーテーブルのタイムゾーンフィールドの選択肢として定義されていることからも明らかです。

したがって、ユーザーテーブルにいる全てのユーザーに適切なタイムゾーンを過不足なく割り当てられるようにタイムゾーンを有効にしましょうということになります。例えば、ユーザー全員が日本にいるインスタンスであれば、タイムゾーンの登録は「Asia/Tokyo」だけでよく、インスタンスの標準タイムゾーンがすでに「Asia/Tokyo」に設定されていれば、その他は全て非有効化して構いません。そして、ユーザーテーブルのユーザー情報にももれなく、タイムゾーンを設定するのが良いでしょう。この、ユーザーにもれなくタイムゾーンを設定するというのは、SLA機能を利用するときにも必要になるものです⁴。

選択できないタイムゾーンを使いたい

たくさんの選択肢が提供されていますが、ServiceNowが提供しているリストは完全なものではありません。この場合、ServiceNowが利用してるJavaがサポートするタイムゾーンであれば新しく追加することができます。以下のドキュメントでもJavaのTimeZoneクラスでサポートするタイムゾーンをサポートするとされています。

例えば、南スーダンの首都ジュバのタイムゾーンはServiceNowのタイムゾーンの選択肢にありませんが、Javaはサポートしているので追加することができます。

これは正しく動作します。ちなみに、Javaでサポートされていないタイムゾーンを無理やり追加すると、エラーなどは起きず単にUTCと同じタイムゾーンとして扱われるようです（やってみたらそうなりました）。

タイムゾーンの重複

ここで、もしかすると、タイムゾーンの登録において、同じ時間帯の複数の表現を重複して登録しないようにすべきではないかと考える方もいらっしゃるかも知れませんが、気にせずに異なる国のタイムゾーンは必要なだけ登録する方が良いと思います。それによってシステム的に問題が起きることもありません。

例えば、日本と韓国には時差がありませんが、日本のユーザーは「Asia/Tokyo」を設定し、韓国のユーザーには「Asia/Seoul」を設定するべきであり、両国の全ユーザーにどちらか一方のタイムゾーンを割り当てるのはあまり良い運用ではないと私は思います。

まとめ

素朴な初期設定の一つなので、新鮮な話ではないかも知れませんが、とりあえずインスタンスを作ると最初に設定するであろう項目の1つとして今日はタイムゾーンの話を考えてみました。

• インスタンスの内部的な時間はUTCで管理されていますが、インスタンスの標準のタイムゾーンは設定可能です。またタイムゾーンはユーザーひとりひとりに紐づけても設定できます。
• 日本で運用するインスタンスであれば、まずは日本標準時「Asis/Tokyo」をまずは有効化したうえで、標準のタイムゾーンにしましょう。
• ユーザーの所在地に合わせて、必要なタイムゾーンはすべて有効化し（逆に不要なものは無効化し）、ユーザーテーブルのタイムゾーンフィールドにもそのユーザーのタイムゾーンを登録しておきましょう。

この辺りの記事はとても参考になります。

1. ServiceNowの本社があるのはカリフォルニア州サンタクララですので、その地域をカバーするタイムゾーンになっていると解するのが自然でしょう。 ↩

2. 多対多テーブルの関連リストの編集メニューなどで使えるスラッシュバケットUIとは微妙に違う、この機能専用のUIだと思われます。 ↩

3. 私が検証したインスタンスでも528個のタイムゾーンが初期状態で登録されています。 ↩

4. サービスレベルアグリーメントのタイムゾーン https://docs.servicenow.com/csh?topicname=r_TimeZones.html&version=latest ↩