6. 制限事項¶

項目

環境
夏時間
プログラミング

本章では、intra-mart Accel Platform のタイムゾーンや夏時間に関する共通的な制限事項を説明します。

6.1. 環境 ¶

6.1.1. 常に最新の Java を利用する必要があります。¶

intra-mart Accel Platform では、Java の API を利用してタイムゾーンの変換を行います。
最新の情報に基づいてタイムゾーンの変換や夏時間の調整を行うには、最新の Java を利用する必要があります。
利用する Java は、常に最新のマイナーバージョンを利用してください。

6.1.2. システムタイムゾーンにはタイムゾーンマスタに定義されているタイムゾーンを設定してください。¶

システムタイムゾーンには「タイムゾーンマスタ」に定義されているタイムゾーンを設定してください。

定義されていないタイムゾーンを指定する場合には、タイムゾーンマスタにタイムゾーンを追加してください。

6.1.3. データベースのタイムゾーンはシステムタイムゾーンと一致させてください。¶

データベースのタイムゾーンはシステムタイムゾーンと一致させてください。

IM-LogicDesigner や ViewCreator で、CURRENT_DATE や CURRENT_TIMESTAMP 等のデータベース側の現在時刻を取得する関数を用いて SQL を作成した場合に、意図せず時刻がズレてしまうことがあります。

6.1.4. システムタイムゾーンには夏時間がないタイムゾーンを指定する必要があります。¶

intra-mart Accel Platform では、システムタイムゾーンには UTC 等の夏時間がないタイムゾーンを指定する必要があります。
システムタイムゾーンに夏時間がないタイムゾーンを指定しなかった場合、日付や日時がズレて表示されてしまう場合があります。
地域に紐づいたタイムゾーンについては、将来的に夏時間が追加される可能性があります。よって、システムタイムゾーンには UTC 等の地域に紐づかないタイムゾーンを指定してください。
Etc/UTC や Etc/GMT-1 等の識別子が Etc/ から始まるタイムゾーンを指定するには、「タイムゾーンマスタ」への追加が必要です。

6.1.5. 運用開始後にシステムタイムゾーンを変更できません。¶

運用開始後にシステムタイムゾーンを変更すると、日時がズレて画面に表示されます。
intra-mart Accel Platform では、「動作仕様を実現するための考え方」に記載の通り、日時をシステムタイムゾーンに変換して保存します。
変更前のシステムタイムゾーンで保存された日時は、そのまま変更後のシステムタイムゾーンの日時として扱われるため、日時がズレた状態で画面に表示されたり、入力情報との比較に利用されたりします。
運用開始後にシステムタイムゾーンを変更しないでください。

6.1.6. TERASOLUNA Server Framework for Java (5.x) for Accel Platform を利用する場合、システムタイムゾーンに一部のタイムゾーンを設定できません。¶

TERASOLUNA Server Framework for Java (5.x) for Accel Platform を利用する場合、システムタイムゾーンに以下のタイムゾーンを設定できません。

Etc/GMT+1 等の + という文字を含むタイムゾーン

6.2. 夏時間 ¶

6.2.1. 夏時間の開始による存在しない日時が入力できてしまいます。¶

「夏時間について」の記載の通り、夏時間開始時にはスキップされる時間帯が存在します。
intra-mart Accel Platform では、スキップされて存在しない日時を画面から入力できる場合があります。
例えば、ニューヨーク（America/New_York）の 2023年3月12日の 2時は夏時間開始により存在しませんが、画面から入力できてしまいます。

画面から入力はできてしまいますが、登録時に登録に失敗した旨のエラーメッセージが表示され、データは登録されません。

6.2.2. 夏時間終了時の重複する日時は、2回目の日時のみ入力可能です。¶

「夏時間について」の記載の通り、夏時間終了時には重複する時間帯が存在します。
intra-mart Accel Platform では、画面から1回目の日時を指定できません。
例えば、ニューヨーク（America/New_York）の 2023年11月5日の 1時は夏時間終了により2回訪れますが、画面上で 2023年11月5日の 1時と入力すると、2回目に訪れる日時（“2023-11-05T01:00:00-05:00”）として登録されます。

6.2.3. 夏時間終了時の日時は、1回目と2回目を見分けることができません。¶

「夏時間について」の記載の通り、夏時間終了時には重複する時間帯が存在します。
intra-mart Accel Platform では、画面上から1回目と2回目の日時を見分けることができません。
例えば、ニューヨーク（America/New_York）の 2023年11月5日の 1時は夏時間終了により2回訪れますが、画面上で1回目（UTC-4）の “2023-11-05T01:00:00-04:00” と2回目（UTC-5）の “2023-11-05T01:00:00-05:00” を見分けることができません。

6.3. プログラミング ¶

6.3.1. クライアントサイド JavaScript の Date オブジェクトを利用して現在時刻を取得しないでください。¶

クライアントサイド JavaScript の Date オブジェクトは、ブラウザやクライアント OS のタイムゾーン設定に基づいて現在時刻を出力します。

ブラウザやクライアント OS のタイムゾーン設定と、アカウントタイムゾーンの設定が一致しているとは限らないため、クライアントサイド JavaScript の Date オブジェクトを利用して現在時刻を取得しないでください。

6.3.2. プログラム内でシステムタイムゾーンを変更しないでください。¶

プログラム内で、java.util.TimeZone#setDefault() 等を用いて、システムタイムゾーンを変更しないでください。

6.3.3. スクリプト開発モデルにおいて、夏時間を表す日時を扱う場合に日付オブジェクト（Date）の文字列表現への変換が正確に行われません。¶

JavaScript の Date インスタンスが以下の条件をすべて満たす場合、Date インスタンスから日付の文字列表現への変換が正確に行われません。1時間ずれた日時に変換されます。

1970 年以前の日付である。

システムタイムゾーンにおける夏時間の期間内である。

※ 「システムタイムゾーンには夏時間がないタイムゾーンを指定する必要があります。」という制限事項から外れた設定をしていた場合に発生します。

※ この現象は、スクリプト開発モデルエンジン（Rhino）の仕様によるものです。

例えば、システムタイムゾーンの日時データを、ユーザのタイムゾーン、および、指定した表示形式（例:「yyyy/MM/dd HH:mm:ss」形式）を使って日時文字列に整形するとします。
Web Application Server のタイムゾーンがJST（日本標準時）になっている場合に以下のコードを実行すると

var date = new Date(1948, 7, 1, 0, 0, 0);
var dateString = DateTimeFormatter.format('yyyy/MM/dd HH:mm:ss', date);

Debug.browse(date.toString(), dateString);

実行結果は、以下です。

date.toString() → Sun Aug 01 1948 00:00:00 GMT+0900 (JST)

dateString → 1948/08/01 01:00:00

まず、タイムゾーンを意識したアプリケーションを実装する場合は、DateTime API を利用して日時を扱ってください。

上記の現象は DateTime API を利用して日付を扱うことで文字列表現への変換を正確に行うことができます。

var systemTimeZone = SystemTimeZone.getDefaultTimeZone().data;
var dateTimeSystemTZ = new DateTime(1948, 7, 1, 0, 0, 0, systemTimeZone);
var dateTimeUserTZ = dateTimeSystemTZ.withTimeZone(Contexts.getAccountContext().timeZone).data;
var dateString = DateTimeFormatter.format('yyyy/MM/dd HH:mm:ss', dateTimeUserTZ);

Debug.browse(dateString);