| Oracle Databaseグローバリゼーション・サポート・ガイド 11gリリース1（11.1） E05757-01 |
|
 前へ |
 次へ |
この章の内容は、次のとおりです。
企業は様々なタイム・ゾーンにまたがってトランザクションを実行しています。Oracleデータベースの日時データ型、期間データ型およびタイム・ゾーン・サポートにより、イベントとトランザクションの時間に関して一貫性のある情報を格納できます。
|
注意: この章では、Oracleデータベースの日時データ型と期間データ型について説明します。特に明記している場合を除き、ANSIデータ型や他の種類のデータ型については説明しません。 |
日時データ型は、DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEです。日時データ型の値をDatetimesと呼ぶこともあります。
期間データ型は、INTERVAL YEAR TO MONTHおよびINTERVAL DAY TO SECONDです。期間データ型の値をIntervalsと呼ぶこともあります。
DatatimesとIntervalsは、どちらも複数のフィールドで構成されます。これらのフィールドの値により、データ型の値が決定されます。Oracleデータベースのすべての日時および期間データ型に適用されるフィールドは、次のとおりです。
YEAR
MONTH
DAY
HOUR
MINUTE
SECOND
TIMESTAMP WITH TIME ZONEには、次のフィールドも含まれます。
TIMEZONE_HOUR
TIMEZONE_MINUTE
TIMEZONE_REGION
TIMEZONE_ABBR
TIMESTAMP WITH LOCAL TIME ZONEはタイム・ゾーン情報の内部格納には使用されませんが、TZH:TZMまたはTZR TZD書式要素が指定されている場合は、SQL出力にローカルのタイム・ゾーン情報を表示できます。
次の項では、日時データ型と期間データ型の詳細を説明します。
|
関連項目: 日時フィールドと時間隔フィールドの有効な値については、『Oracle Database SQLリファレンス』を参照してください。書式要素については、『Oracle Database SQLリファレンス』も参照してください。 |
この項の内容は、次のとおりです。
DATEデータ型を使用して、日付および時刻情報が格納されます。日付および時刻情報はCHARACTERおよびNUMBERデータ型の両方で表現できますが、DATEデータ型は特別に関連付けられているプロパティがあります。DATE値ごとに、次の世紀、年、月、日、時間、分および秒の情報が格納されます。
日付値は次の方法で指定できます。
日付値をリテラルとして指定
TO_DATE関数を使用して文字値または数値を日付値に変換
日付は、ANSI日付リテラルまたはOracleデータベースの日付値として指定できます。
ANSI日付リテラルには時間部分がなく、次の書式で正確に指定する必要があります。
DATE 'YYYY-MM-DD'
次にANSI日付リテラルの例を示します。
DATE '1998-12-25'
または、次の例に示すようにOracleデータベースの日付値を指定することもできます。
TO_DATE('1998-DEC-25 17:30','YYYY-MON-DD HH24:MI','NLS_DATE_LANGUAGE=AMERICAN')
Oracleデータベースの日付値のデフォルト書式は、NLS_DATE_FORMATおよびNLS_DATE_LANGUAGE初期化パラメータから導出されます。この例の日付書式には、日を表す2桁の数値、月名の略称、年の最後の2桁および24時間指定が含まれています。NLS_DATE_LANGUAGEの指定が含まれていますが、これはどのロケールでも'DEC'はMONに有効な値ではないためです。
デフォルト日付書式の文字値が日付式に使用されている場合は、自動的に日付値に変換されます。
時刻要素を含めずに日付値を指定した場合、デフォルトの時刻として午前0時に設定されます。日付を含めずに日付値を指定した場合、デフォルトの日付として現在の月の第1日に設定されます。
OracleデータベースのDATEの列には、常に日付と時刻の両方のフィールドが含まれます。時刻部分を指定せずに問合せに日付書式を使用する場合は、DATE列の時刻フィールドが午前0時に設定されていることを確認する必要があります。TRUNC (date) SQL関数を使用すると、時刻フィールドが午前0時に設定されていることを確認できます。また、問合せを使用して等価性または非等価性（=または!=）のかわりに大小の関係（<、<=、>=または>）のテストもできます。時刻フィールドが午前0時に設定されていない場合、Oracleデータベースでは予期した問合せ結果が戻されないことがあります。
|
関連項目:
|
TIMESTAMPデータ型は、DATEデータ型の拡張です。このデータ型を使用して、年、月、日、時間、分および秒の値が格納されます。また、DATEデータ型では格納されない小数秒も格納されます。
TIMESTAMPデータ型は次のように指定します。
TIMESTAMP [(fractional_seconds_precision)]
fractional_seconds_precisionはオプションで、SECOND日時フィールドの小数部の桁数を指定します。値の範囲は0〜9で、デフォルトは6です。
たとえば、'26-JUN-02 09:39:16.78'は16.78秒を示します。78は2桁のため、小数秒の精度は2です。
TIMESTAMPリテラルは、次のような書式で指定できます。
TIMESTAMP 'YYYY-MM-DD HH24:MI:SS.FF'
この例に示す書式を使用して、次のようにTIMESTAMPをリテラルとして指定します。
TIMESTAMP '1997-01-31 09:26:50.12'
NLS_TIMESTAMP_FORMAT初期化パラメータの値により、文字列からTIMESTAMPデータ型への変換時のタイムスタンプ書式が決定されます。NLS_DATE_LANGUAGEにより、MONなど、文字データの使用言語が決定されます。
|
関連項目:
|
TIMESTAMP WITH TIME ZONEはTIMESTAMPのバリアントで、値にはタイム・ゾーン・リージョン名またはタイム・ゾーン・オフセットが含まれます。タイム・ゾーン・オフセットは、ローカル時間とUTC（協定世界時、以前のグリニッジ標準時）との時差（時間および分単位）です。TIMESTAMP WITH TIME ZONEデータ型は次のように指定します。
TIMESTAMP [(fractional_seconds_precision)] WITH TIME ZONE
fractional_seconds_precisionはオプションで、SECOND日時フィールドの小数部の桁数を指定します。
TIMESTAMP WITH TIME ZONEは、次のようにリテラルとして指定できます。
TIMESTAMP '1997-01-31 09:26:56.66 +02:00'
2つのTIMESTAMP WITH TIME ZONE値がUTCで同じ時刻を表している場合は、データに格納されているTIME ZONEのオフセットに関係なく同一とみなされます。たとえば、次の2つの式の値は同じです。
TIMESTAMP '1999-01-15 8:00:00 -8:00' TIMESTAMP '1999-01-15 11:00:00 -5:00'
UTCオフセットはTZR（タイム・ゾーン・リージョン）書式要素で置き換えることができます。次の式は、タイム・ゾーン・リージョンにUS/Pacificを指定しています。
TIMESTAMP '1999-01-15 8:00:00 US/Pacific'
標準時間から夏時間への切替時に境界を明確にするには、TZR書式要素および対応するTZD書式要素の両方を使用します。TZD書式要素は、夏時間情報を含むタイム・ゾーン・リージョンの略称です。たとえば、米国/太平洋標準時間の場合はPST、米国/太平洋夏時間の場合はPDTです。次のように指定すると、確実に夏時間の値が戻されます。
TIMESTAMP '1999-10-29 01:30:00 US/Pacific PDT'
ERROR_ON_OVERLAP_TIMEセッション・パラメータをTRUEに設定していて、TZD書式要素を追加しない場合、日時の値が不明確な場合はエラーが戻されます。ERROR_ON_OVERLAP_TIMEがFALSE（デフォルト値）に設定されている場合、あいまいな日時は標準時間として解析されます。
TIMESTAMP WITH TIME ZONEデータ型のデフォルトの日付書式は、NLS_TIMESTAMP_TZ_FORMAT初期化パラメータの値により決定されます。
|
関連項目:
|
TIMESTAMP WITH LOCAL TIME ZONEは、TIMESTAMPのもう1つのバリアントです。TIMESTAMP WITH TIME ZONEとは異なり、データベースに格納されるデータはデータベースのタイム・ゾーンに対して正規化され、タイム・ゾーン・オフセットは列データの一部として格納されません。ユーザーがデータを検索すると、そのユーザーのローカル・セッションのタイム・ゾーンで戻されます。タイム・ゾーン・オフセットは、ローカル時間とUTC（協定世界時、以前のグリニッジ標準時）との時差（時間および分単位）です。
TIMESTAMP WITH LOCAL TIME ZONEデータ型は次のように指定します。
TIMESTAMP [(fractional_seconds_precision)] WITH LOCAL TIME ZONE
fractional_seconds_precisionはオプションで、SECOND日時フィールドの小数部の桁数を指定します。
TIMESTAMP WITH LOCAL TIME ZONEのリテラルはありませんが、TIMESTAMP WITH LOCAL TIME ZONE列にTIMESTAMPリテラルとTIMESTAMP WITH TIME ZONEリテラルを挿入できます。
TIMESTAMP WITH LOCAL TIME ZONEデータ型のデフォルトの日付書式は、NLS_TIMESTAMP_FORMAT初期化パラメータの値により決定されます。
|
関連項目:
|
適切なNLS書式値に基づく書式を使用した文字列の挿入
リテラルの挿入
暗黙的な変換の実行対象となるリテラルの挿入
TO_TIMESTAMP、TO_TIMESTAMP_TZまたはTO_DATE SQL関数の使用
次の例に、日時データ型にデータを挿入する方法を示します。
例4-1 DATE列へのデータの挿入
日付書式を設定します。
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS';
c_id列とc_dt列を含むtable_dt表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_dt列はDATEデータ型です。
SQL> CREATE TABLE table_dt (c_id NUMBER, c_dt DATE);
日付を文字列として挿入します。
SQL> INSERT INTO table_dt VALUES(1, '01-JAN-2003');
同じ日付をDATEリテラルとして挿入します。
SQL> INSERT INTO table_dt VALUES(2, DATE '2003-01-01');
同じ日付をTIMESTAMPリテラルとして挿入します。タイム・ゾーン情報は削除されます。
SQL> INSERT INTO table_dt VALUES(3, TIMESTAMP '2003-01-01 00:00:00 US/Pacific');
TO_DATE関数を使用して同じ日付を挿入します。
SQL> INSERT INTO table_dt VALUES(4, TO_DATE('01-JAN-2003', 'DD-MON-YYYY'));
データを表示します。
SQL> SELECT * FROM table_dt; C_ID C_DT ---------- -------------------- 1 01-JAN-2003 00:00:00 2 01-JAN-2003 00:00:00 3 01-JAN-2003 00:00:00 4 01-JAN-2003 00:00:00
例4-2 TIMESTAMP列へのデータの挿入
タイムスタンプ書式を設定します。
SQL> ALTER SESSION SET NLS_TIMESTAMP_FORMAT='DD-MON-YY HH:MI:SSXFF';
c_id列とc_ts列を含むtable_ts表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_ts列はTIMESTAMPデータ型です。
SQL> CREATE TABLE table_ts(c_id NUMBER, c_ts TIMESTAMP);
日付と時刻を文字列として挿入します。
SQL> INSERT INTO table_ts VALUES(1, '01-JAN-2003 2:00:00');
同じ日付および時刻をTIMESTAMPリテラルとして挿入します。
SQL> INSERT INTO table_ts VALUES(2, TIMESTAMP '2003-01-01 2:00:00');
同じ日付および時刻をTIMESTAMP WITH TIME ZONEリテラルとして挿入します。挿入した値はTIMESTAMP値に変換されます。つまり、タイム・ゾーン情報が削除されます。
SQL> INSERT INTO table_ts VALUES(3, TIMESTAMP '2003-01-01 2:00:00 -08:00');
データを表示します。
SQL> SELECT * FROM table_ts; C_ID C_TS ---------- ----------------------------- 1 01-JAN-03 02:00:00.000000 AM 2 01-JAN-03 02:00:00.000000 AM 3 01-JAN-03 02:00:00.000000 AM
この3つの方法では、いずれも同じ値が格納されることに注意してください。
例4-3 TIMESTAMP WITH TIME ZONEデータ型へのデータの挿入
タイムスタンプ書式を設定します。
SQL> ALTER SESSION SET NLS_TIMESTAMP_TZ_FORMAT='DD-MON-RR HH:MI:SSXFF AM TZR';
タイム・ゾーンを'-07:00'に設定します。
SQL> ALTER SESSION SET TIME_ZONE='-7:00';
c_id列とc_tstz列を含むtable_tstz表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_tstz列はTIMESTAMP WITH TIME ZONEデータ型です。
SQL> CREATE TABLE table_tstz (c_id NUMBER, c_tstz TIMESTAMP WITH TIME ZONE);
日付と時刻を文字列として挿入します。
SQL> INSERT INTO table_tstz VALUES(1, '01-JAN-2003 2:00:00 AM -07:00');
同じ日付および時刻をTIMESTAMPリテラルとして挿入します。挿入した値はTIMESTAMP WITH TIME ZONEリテラルに変換されます。つまり、TIMESTAMP値にセッションのタイム・ゾーンが追加されます。
SQL> INSERT INTO table_tstz VALUES(2, TIMESTAMP '2003-01-01 2:00:00');
同じ日付および時刻をTIMESTAMP WITH TIME ZONEリテラルとして挿入します。
SQL> INSERT INTO table_tstz VALUES(3, TIMESTAMP '2003-01-01 2:00:00 -8:00');
データを表示します。
SQL> SELECT * FROM table_tstz; C_ID C_TSTZ ---------- ------------------------------------ 1 01-JAN-03 02:00.00:000000 AM -07:00 2 01-JAN-03 02:00:00.000000 AM -07:00 3 01-JAN-03 02:00:00.000000 AM -08:00
方法3の場合はタイム・ゾーンが異なることに注意してください。これは、TIMESTAMP WITH TIME ZONEリテラルの一部としてタイム・ゾーン情報が指定されているためです。
例4-4 TIMESTAMP WITH LOCAL TIME ZONEデータ型へのデータの挿入
タイム・ゾーンがUTC-7である米国コロラド州デンバーで入力されるデータを考えます。
SQL> ALTER SESSION SET TIME_ZONE='-07:00';
c_id列とc_tsltz列を含むtable_tsltz表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_tsltz列はTIMESTAMP WITH LOCAL TIME ZONEデータ型です。
SQL> CREATE TABLE table_tsltz (c_id NUMBER, c_tsltz TIMESTAMP WITH LOCAL TIME ZONE);
日付と時刻を文字列として挿入します。
SQL> INSERT INTO table_tsltz VALUES(1, '01-JAN-2003 2:00:00');
同じデータをTIMESTAMP WITH LOCAL TIME ZONEリテラルとして挿入します。
SQL> INSERT INTO table_tsltz VALUES(2, TIMESTAMP '2003-01-01 2:00:00');
同じデータをTIMESTAMP WITH TIME ZONEリテラルとして挿入します。データはTIMESTAMP WITH LOCAL TIME ZONE値に変換されます。つまり、入力したタイム・ゾーン（-08:00）はセッションのタイム・ゾーン値（-07:00）に変換されます。
SQL> INSERT INTO table_tsltz VALUES(3, TIMESTAMP '2003-01-01 2:00:00 -08:00');
データを表示します。
SQL> SELECT * FROM table_tsltz; C_ID C_TSLTZ ---------- ------------------------------------ 1 01-JAN-03 02.00.00.000000 AM 2 01-JAN-03 02.00.00.000000 AM 3 01-JAN-03 03.00.00.000000 AM
時間が2から3に変更され、UTC-8として入力した情報がローカル・タイム・ゾーンに変更されていることに注意してください。
TIMESTAMPデータ型を使用するのは、ロケール情報なしの日時値が必要な場合です。たとえば、組立ラインの作業場にいる従業員がタイムカードに出社と退社を記録した時刻情報を格納できます。TIMESTAMPデータ型では、格納に7バイトまたは11バイトが使用されます。
TIMESTAMP WITH TIME ZONEデータ型を使用するのは、アプリケーションがタイム・ゾーンにまたがって使用される場合です。世界各地に支店を持つ銀行を考えます。午前11時にロンドンで口座への入金が記録され、午前9時にニューヨークで口座からの同額出金が記録されるとします。この場合、口座には3時間だけ預金があることになります。口座トランザクションとともにタイム・ゾーン情報が格納されなければ、この口座は午前9時から午前11時まで超過引出しとなります。
TIMESTAMP WITH TIME ZONEデータ型では、タイム・ゾーン情報が格納されるため、データの格納にTIMESTAMPおよびTIMESTAMP WITH LOCAL TIME ZONEデータ型よりも2バイト多い13バイトが必要です。タイム・ゾーンは、UTCからのオフセットまたはタイム・ゾーン・リージョン名として格納されます。データはそのまま表示または計算に使用でき、追加の処理は必要ありません。TIMESTAMP WITH TIME ZONE列は主キーとして使用できません。TIMESTAMP WITH TIME ZONE列で索引が作成されると、ファンクション索引となります。
TIMESTAMP WITH LOCAL TIME ZONEデータ型は、タイム・ゾーン情報のないタイムスタンプの格納に使用されます。データは、クライアントとの間でやりとりされるたびにデータベースのタイム・ゾーンに対して正規化されます。格納には11バイトが必要です。
TIMESTAMP WITH LOCAL TIME ZONEデータ型は、元のタイム・ゾーンは重要ではないが、イベントの相対時刻が重要な場合に適しています。前述の銀行の例で説明したトランザクションを考えます。データがTIMESTAMP WITH LOCAL TIME ZONEデータ型を使用して記録されるとします。銀行のデータベースのタイム・ゾーンがAsia/Hong_Kongに設定されている場合、香港の従業員がデータを表示すると、午後7時に入金があり、午後10時に出金があったことがわかります。同じデータをロンドンで表示すると、午前11時に入金があり、午後2時に出金があったことが示されます。3時間の時差は維持されますが、元のトランザクションのタイム・ゾーン/リージョンは維持されません。このため、トランザクションの実際の時刻の解析は、情報の取得先タイム・ゾーン/リージョンによって異なります。たとえば、ロンドンでは、トランザクションが営業時間中のものとなりますが、香港では営業時間外になります。
TIMESTAMP WITH LOCAL TIME ZONEデータ型では、時間データの元のタイム・ゾーン/リージョンが維持されないため、夏時間への移行日が頻繁に更新され期間も変則的なブラジルやイスラエルなどのリージョンからの時間に関する時間データは、不正確な場合があります。これらの地域からの時間情報がキーとなるアプリケーションの場合は、別の日時データ型の利用を考慮できます。
期間データ型は、期間の格納に使用されます。主な用途は分析関数です。たとえば、株価の移動平均の計算に使用できます。特定のパーセンタイルに対応する値を判別するには、期間データ型を使用する必要があります。また、期間データ型は履歴表の更新にも使用できます。
この項の内容は、次のとおりです。
|
関連項目: 移動平均や逆パーセンタイルなどの分析関数の詳細は、『Oracleデータ・ウェアハウス・ガイド』を参照してください。 |
INTERVAL YEAR TO MONTHでは、YEARおよびMONTH日時フィールドを使用して期間が格納されます。INTERVAL YEAR TO MONTHは次のように指定します。
INTERVAL YEAR [(year_precision)] TO MONTH
year_precisionは、YEAR日時フィールドの桁数です。year_precisionの許容値は0〜9で、デフォルト値は2です。
時間隔値は、リテラルとして指定できます。時間隔リテラルを指定するには様々な方法があります。次に、123年と2か月の時間隔を指定する一例を示します。年の精度は3です。
INTERVAL '123-2' YEAR(3) TO MONTH
|
関連項目: INTERVAL YEAR TO MONTHデータ型を使用して時間隔リテラルを指定する方法の詳細は、『Oracle Database SQLリファレンス』を参照してください。 |
INTERVAL DAY TO SECONDでは、期間が日、時間、分および秒単位で格納されます。このデータ型は次のように指定します。
INTERVAL DAY [(day_precision)] TO SECOND [(fractional_seconds_precision)]
day_precisionは、DAY日時フィールドの桁数です。許容値は0〜9で、デフォルト値は2です。
fractional_seconds_precisionは、SECOND日時フィールドの小数部の桁数を指定します。許容値は0〜9で、デフォルト値は6です。
次に、4日、5時間、12分、10秒および0.222秒の時間隔を指定する一例を示します。小数秒の精度は3です。
INTERVAL '4 5:12:10.222' DAY TO SECOND(3)
時間隔値は、リテラルとして指定できます。時間隔リテラルを指定するには様々な方法があります。
|
関連項目: INTERVAL DAY TO SECONDデータ型を使用して時間隔リテラルを指定する方法の詳細は、『Oracle Database SQLリファレンス』を参照してください。 |
この項の内容は、次のとおりです。
日付（DATE）、タイムスタンプ（TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE）および時間隔（INTERVAL DAY TO SECOND、INTERVAL YEAR TO MONTH）の各データに対する演算操作を実行できます。タイムスタンプ・データ型を期間データ型と併用すると、演算操作で最大精度を維持できます。
日付値とタイムスタンプ値に対する演算操作には、NUMBER定数を使用できます。タイムスタンプ値はOracleで内部的に日付値に変換されてから、NUMBER定数を使用して演算操作が実行されます。これは、日付値とタイムスタンプ値の両方を含む操作中には、小数秒に関する情報が失われることを意味します。日時式および時間隔式では、NUMBER定数が日数として解析されます。
各DATE値には、時間要素が含まれます。多くの日付操作の結果には、小数部があります。この小数部は、1日の一部分を表します。たとえば、1.5日は36時間です。DATEデータに対する一般的な操作では、これらの小数部もOracleデータベースの組込みSQL関数により戻されます。たとえば、組込みMONTHS_BETWEEN SQL関数は、2つの日付間の月数を戻します。結果の小数部は、大の月である1か月のうちの該当部分を表します。
Oracleデータベースでは、すべてのタイムスタンプ演算がUTC時間で実行されます。TIMESTAMP WITH LOCAL TIME ZONEデータの場合は、日時値がデータベースのタイム・ゾーンからUTCに変換され、演算の実行後にデータベースのタイム・ゾーンに逆変換されます。TIMESTAMP WITH TIME ZONEデータの場合、日時値には常にUTCが使用されるため、変換は必要ありません。
|
関連項目:
|
日付値とタイムスタンプ値を比較する場合、Oracleデータベースではデータが高精度のデータ型に変換されてから比較されます。たとえば、TIMESTAMP WITH TIME ZONEデータ型のデータをTIMESTAMPデータ型のデータと比較する場合は、セッションのタイム・ゾーンを使用してTIMESTAMPデータがTIMESTAMP WITH TIME ZONEに変換されます。
日付およびタイムスタンプ・データの変換の優先順位は次のとおりです。
DATE
TIMESTAMP
TIMESTAMP WITH LOCAL TIME ZONE
TIMESTAMP WITH TIME ZONE
どのデータ型のペアの場合も、優先順位リストで小さい番号を持つデータ型が、大きい番号を持つデータ型に変換されます。
日時関数は、日付（DATE）、タイムスタンプ（TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE）および時間隔（INTERVAL DAY TO SECOND、INTERVAL YEAR TO MONTH）の値を処理します。
日時関数の一部は、OracleデータベースのDATEデータ型用に設計されています。引数としてタイムスタンプ値を指定すると、Oracleデータベースでは内部的に入力の型がDATE値に変換されます。ROUNDおよびTRUNC関数の場合、内部変換は実行されません。
表4-1に、OracleのDATEデータ型用に設計されている日時関数を示します。この表には、各関数の詳細へのクロス・リファレンスが含まれています。
表4-1 DATEデータ型用に設計された日時関数
| 関数 | 説明 |
|---|---|
|
|
|
|
|
|
|
|
|
|
注意: この関数への入力として使用できるタイム・ゾーンの数は限定されています。 |
|
|
名前に |
|
|
|
|
|
日の時刻部分を |
表4-2に、その他の日時関数と詳細説明へのクロス・リファレンスを示します。
表4-2 その他の日時関数
| 日時関数 | 説明 |
|---|---|
|
グレゴリオ暦による値のうちセッションのタイム・ゾーンの現在の日付を |
|
|
セッションのタイム・ゾーンの現在の日時を |
|
|
データベースのタイム・ゾーンの値を戻します。この値は、タイム・ゾーン・オフセットまたはタイム・ゾーン・リージョン名です。 |
|
|
日時値または時間隔値の式から、指定された日時フィールドの値を抽出して戻します。 |
|
|
タイム・ゾーンの |
|
|
セッションのタイム・ゾーンの現在の日時を |
|
|
数値 |
|
|
数値 |
|
|
現行セッションのタイム・ゾーンの値を戻します。 |
|
|
タイム・ゾーン・オフセットを使用して日時からUTCを抽出します。 |
|
|
データベースの起動時に有効だったデータベース・サーバーのオペレーティング・システムのタイム・ゾーンを考慮して、データベースが常駐するオペレーティング・システムの日時を戻します。 |
|
|
データベースが常駐するシステムの小数秒とタイム・ゾーンを含めてシステム日付を戻します。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
文が実行される日付に基づいて、入力値に対応するタイム・ゾーン・オフセットを戻します。 |
|
関連項目: 『Oracle Database SQLリファレンス』 |
この項の内容は、次のとおりです。
表4-3に、日時書式パラメータの名前と説明を示します。
表4-3 日時書式パラメータ
| パラメータ | 説明 |
|---|---|
|
|
|
|
|
デフォルト値はNLS_TERRITORYから導出されます。
値は、初期化パラメータ・ファイル内で設定することで指定できます。クライアントの場合は、値をクライアント環境変数として指定できます。
また、初期化パラメータ・ファイルでその値を変更してインスタンスを再起動すると、値を変更できます。
セッション中に値を変更するには、ALTER SESSION文を使用します。
Oracleデータベースタイム・ゾーン・ファイルには、有効なタイム・ゾーン名が含まれています。タイム・ゾーンごとに次の情報も含まれています。
協定世界時（UTC）からのオフセット。
夏時間への移行時間。
標準時間と夏時間の略称。
Oracleデータベースのホーム・ディレクトリには、2つのタイム・ゾーン・ファイルがあります。デフォルトのタイム・ゾーン・ファイルは$ORACLE_HOME/oracore/zoneinfo/timezonelrg.datです。このファイルには、データベースで定義されているすべてのタイム・ゾーンが含まれています。$ORACLE_HOME/oracore/zoneinfo/timezone.datには、最も一般的なタイム・ゾーンのみが含まれています。
大きい方のタイム・ゾーン・ファイルを使用している場合は、データベースに格納されたデータに、大きい方のファイルに含まれる追加タイム・ゾーンが使用されていないことが明らかである場合を除き、引き続き大きい方のファイルを使用する必要があります。また、情報を共有するすべてのデータベースとクライアントのインストールでは、同じタイム・ゾーン・ファイルを使用する必要があります。
$ORACLE_HOM/oracore/zoneinfo/timezone.datを使用可能にする手順、またはすでにタイム・ゾーン・ファイルとしてこのファイルを使用しており、Oracle Database 11g環境でも引き続きこのファイルを使用する手順は、次のとおりです。
データベースが起動している場合はシャットダウンします。
環境変数ORA_TZFILEを$ORACLE_HOME/oracore/zoneinfo/timezone.datに設定します。
データベースを再起動します。
|
注意: デフォルトのタイム・ゾーン・ファイルをすでに使用している場合、データベースには小さい方のタイム・ゾーン・ファイルに含まれていないタイム・ゾーンを使用するデータが含まれていることがあるため、小さい方のタイム・ゾーン・ファイルに変更するのは実用的ではありません。 |
Oracleデータベースのタイム・ゾーン・データは、ftp://elsie.nci.nih.gov/pub/で使用可能な公開情報から導出されます。Oracleデータベースのタイム・ゾーン・データには、このサイトから入手可能な最新データが反映されていない場合があります。
次の文を入力すると、データベースとともにインストールされるタイム・ゾーン・ファイルからタイム・ゾーンの名前と略称のリストを取得できます。
SELECT tzname, tzabbrev FROM V$TIMEZONE_NAMES;
デフォルトのタイム・ゾーン・ファイルの場合、この文の出力は次のようになります。
TZNAME TZABBREV -------------------- ---------- Africa/Algiers LMT Africa/Algiers PMT Africa/Algiers WET Africa/Algiers WEST Africa/Algiers CET Africa/Algiers CEST Africa/Cairo LMT Africa/Cairo EET Africa/Cairo EEST Africa/Casablanca LMT Africa/Casablanca WET Africa/Casablanca WEST Africa/Casablanca CET ... W-SU LMT W-SU MMT W-SU MST W-SU MDST W-SU S W-SU MSD W-SU MSK W-SU EET W-SU EEST WET LMT WET WEST WET WET 1393 rows selected.
Africa/Algiersタイム・ゾーンには6つのタイム・ゾーン略称が、Africa/Cairoタイム・ゾーンには3つの略称が、またAfrica/Casablancaタイム・ゾーンには4つの略称が関連付けられています。次の表に、タイム・ゾーン略称とその意味を示します。
| タイム・ゾーン略称 | 意味 |
|---|---|
| LMT | ローカル標準時間 |
| PMT | パリ標準時間 |
| WET | 西ヨーロッパ時間 |
| WEST | 西ヨーロッパ夏時間 |
| CET | 中央ヨーロッパ時間 |
| CEST | 中央ヨーロッパ夏時間 |
| EET | 東ヨーロッパ時間 |
| EEST | 東ヨーロッパ夏時間 |
1つの略称が複数のタイム・ゾーンに関連付けられている場合があるため注意してください。たとえば、CETは、ヨーロッパのタイム・ゾーンに加えてAfrica/AlgiersとAfrica/Casablancaの両方に関連付けられています。
略称ごとにタイム・ゾーン名が繰り返されないタイム・ゾーン・リストが必要な場合は、次の問合せを使用します。
SELECT UNIQUE tzname FROM V$TIMEZONE_NAMES;
デフォルトのタイム・ゾーン・ファイルの場合、この出力結果は次のようになります。
TZNAME -------------------- Africa/Algiers Africa/Cairo Africa/Casablanca Africa/Ceuta ... US/Pacific US/Pacific-New US/Samoa UTC W-SU WET
デフォルトのタイム・ゾーン・ファイルには、350を超える一意のタイム・ゾーン名が含まれています。小さいタイム・ゾーン・ファイルには、180を超える一意のタイム・ゾーン名が含まれています。
Oracleデータベースによって提供されるタイム・ゾーン・ファイルを定期的にアップグレードして、様々なタイム・ゾーン・リージョンに対する変更を反映します。Oracle Database 11gで提供されているタイム・ゾーン・ファイルは、バージョン3に更新されました。このバージョンには、2007年から始まる米国タイム・ゾーンの夏時間（DST）ルールに関する最新の変更が含まれています。
|
注意: Oracle Database 9iには、タイム・ゾーン・ファイルのバージョン1、そして、Oracle Database 10gにはバージョン2のファイルが含まれています。これらのリリースそれぞれに様々なパッチとパッチ・セットが提供されていて、そのようなパッチやパッチ・セットによってもタイム・ゾーン・ファイルは更新されます。 |
OracleデータベースはTIMESTAMP WITH TIME ZONEデータ型のデータを内部的に格納するので、DSTトランジッション・ルールに対する変更は、このデータ型の既存データに影響を与える可能性があります。ユーザーがタイム・ゾーン付きのタイムスタンプを入力すると、Oracleデータベースは、そのタイム・ゾーンのトランジッション・ルールに基づいて、そのデータをUTCに変換し、もともとのタイム・ゾーンIDとともに、そのデータをディスクに格納します。データを取り出すときは、UTCからの逆変換が起こります。たとえば、バージョン2のトランジッション・ルールを適用した場合、TIMESTAMP '2007-11-02 12:00:00 America/Los_Angeles'は、UTCの値'2007-11-02 20:00:00'と'America/Los_Angeles'のタイム・ゾーンIDとして格納されました。ロサンゼルス時間は、UTC-8時間（PST）です。バージョン3のトランジッション・ルールの場合、同じ日のオフセットは-7時間（PDT）です。2007年から、DSTは今までよりも長い期間に有効になります（11月の第1日曜日、つまり2007年の11月4日まで）。先ほどのタイムスタンプをユーザーが取り出すと、格納されていたUTC時間に新しいオフセットが適応され、TIMESTAMP '2007-11-02 13:00:00 America/Los_Angeles'になります。以前のデータとバージョン3が適用されたデータの間には1時間の差があります。
一般的に、TIMESTAMP '2007-11-02 12:00:00 America/Los_Angeles'という値は、ロサンゼルス時間の2007年11月2日正午を意味します。DSTトランジッション・ルールの変更によって1時間のずれが生じるので、この項で詳しく説明しているように、タイムスタンプを更新して午後12時00分に戻す必要があります。まれではありますが、この値は、UTC時間で午後8時00分のときのロサンゼルス現地時間を意味していることがあります。このまれなケースでは、タイム・ゾーン・ファイルが更新された後でのみ、実際に値が訂正されます。この場合、それ以外の訂正は不要です。したがって、タイムスタンプの値が更新される前に、その値が何を意味するか理解することが重要です。
|
注意: トランジッション・ルールが更新されるタイム・ゾーン・リージョンの場合、この「タイム・ゾーン・ファイルのアップグレード」で説明した問題は、該当するDSTルール変更の試行期日よりも未来を指し示すタイムスタンプに対してのみ影響を与えます。たとえば、2007年よりも前のタイムスタンプには、'America/Los_Angeles'タイム・ゾーン・リージョンのバージョン3による影響はありません。 |
$ORACLE_HOME/rdbms/admin/utltzuv2.sqlスクリプトを使用すると、タイム・ゾーン・ファイルの更新による影響が予想されるデータベース内のTIMESTAMP WITH TIME ZONEデータ型のすべての列を検出できます。結果は、sys.sys_tzuv2_temptab表に格納され、この表には、table_owner、table_name、column_name、rowcountおよびnested_tabという5つの列があります。sys.sys_tzuv2_temptabの各行は、TIMESTAMP WITH TIME ZONE表の列を説明します。（a）タイム・ゾーン・ファイルの更新による影響を受けるいずれかのタイム・ゾーン・リージョンの少なくとも1つのタイムスタンプを含んでいるか、または（b）ネスト化された表に所属するかというような情報を示します。nested_tabの値が、'YES'ならば、条件（b）により、table_nameで指定された表が挿入されていることを表します。パフォーマンスの理由から、ネストされた表の列はタイム・ゾーン・リージョンよって影響を受ける内容をスキャンしなくても報告されます。条件（a）により挿入された列の場合、rowcountの値には影響を受けたタイム・ゾーン・リジョンの1つを含む列のタイムスタンプ数が入ります。
utltzuv2.sqlスクリプトは、データベースのタイム・ゾーン・ファイルを更新する前に実行する必要があります。このスクリプトは、データベース・タイム・ゾーン・ファイルの現バージョンと、スクリプトが作成されたタイム・ゾーン・ファイルのバージョンを比較することによって、どのタイム・ゾーン・リージョンを見つけ出すか特定します。データベースのタイム・ソーン・ファイルがすぐに更新される場合、2つのバージョンが等しいとして、スクリプトは何も作用しません。以前のリリースからOracleデータベース・ソフトウェアがアップグレードされた、あるいはパッチ・セットが適用された結果として、タイム・ゾーン・ファイルが変わった場合、データベースをアップグレードするまえにこのスクリプトを実行する必要があります。したがって、ソフトウェアを新しくインストールする前には、古いソフトウェアのバージョンと新しいタイム・ゾーン・ファイルのバージョンとの組合せに対して適切なutltzuv2.sqlパッチを見つけ出し、インストールする必要があります。
|
関連項目: 使用可能なパッチのマトリクスについては、Oracle MetaLinkサイトhttp://metalink.oracle.comをアクセスし、Document ID 396906.1を参照してください。 |
utltzuv2.sqlスクリプトを実行するためには、SQL*Plusを開始し、SYSDBAでログインして、次のコマンドを実行します。
SQL> @?/rdbms/admin/utltzuv2.sql
タイム・ゾーン・ファイルの更新の影響を受けるデータがデータベースに含まれている場合は、先に説明したように、タイム・ゾーン・ファイルをアップグレードする前に、他の書式でタイムスタンプデータをバックアップします。アップグレード後、作成しておいたバックアップを使用してデータを更新し、新しいルールに基づいてデータが格納されることを確認します。
次の例で更新プロセスを示します。
例4-5 タイム・ゾーン・ファイルのアップグレードおよび影響を受けるタイムスタンプ・データの修正
アプリケーション・データの表に、TIMESTAMP WITH TIME ZONE列が含まれているとします。
CREATE TABLE tztab(x NUMBER PRIMARY KEY, y TIMESTAMP WITH TIME ZONE); INSERT INTO tztab VALUES(1, TIMESTAMP '2007-11-02 12:00:00 America/Los_Angeles');
アップグレードする前に、テキスト書式のyの列からタイムスタンプをバックアップするために、tztab_back表を作成します。
CREATE TABLE tztab_back(x NUMBER PRIMARY KEY, y VARCHAR2(256)); INSERT INTO tztab_back SELECT x, TO_CHAR(y, 'YYYY-MM-DD HH24.MI.SSXFF TZR') FROM tztab;
処理する行数を少なくするために、WHERE句を追加して、タイム・ゾーン・リージョンの変更によって影響を受けるタイムスタンプのみをバックアップします。この例では、次のようなWHERE句を使用します。
WHERE y > TIMESTAMP '2007-01-01 00:00:00 +00:00'
アップグレード後、次のようにtztab_backの値を使用して、tztab表のデータを更新します。
UPDATE tztab t SET t.y =
(SELECT to_timestamp_tz(t1.y,'YYYY-MM-DD HH24.MI.SSXFF TZR')
FROM tztab_back t1
WHERE t.x = t1.x);
tztab_backにデータを入れる際にWHERE句を使用した場合は、次のようにUPDATEにも同じ句を追加します。
UPDATE tztab t SET t.y =
(SELECT to_timestamp_tz(t1.y,'YYYY-MM-DD HH24.MI.SSXFF TZR')
FROM tztab_back t1
WHERE t.x = t1.x)
WHERE t.y > TIMESTAMP '2007-01-01 00:00:00 +00:00'
|
注意: タイムスタンプは内部ストレージ書式でエクスポートされるため、エクスポート・ユーティリティによるタイムスタンプの訂正はできません。後にインポートが続くエクスポートは決して、値を変更しません。 |
移行ルールの変更はTIMESTAMP WITH LOCAL TIME ZONEデータ型のデータに影響を与える場合がありますが、データをアップグレードする方法はありません。このデータ型はデータに関連付けられている元のタイム・ゾーン/リージョンを維持しないため、データをアップグレードできません。
データベースのタイム・ゾーン・ファイルを更新するカスタマ、および新しいファイル・バージョンの影響があるタイム・ゾーン・リージョンを使用しているカスタマはすべてのデータベース・クライアントのタイム・ゾーン・ファイルを更新する必要があります。さらに、このようなデータベースと通信する他のデータベースもすべて、同じバージョンに更新する必要があります。これによって、すべてのデータベース環境が同じタイム・ゾーン・ファイルのバージョンを使用することになります。この処理は、影響を受けるリージョンを使用していないカスタマに対しては不要です。しかし、オラクル社はすべてのデータベース環境におけるタイム・ゾーン・ファイルのバージョンを合せることを推奨します。
|
注意: タイム・ゾーン・ファイルを更新するために使用可能なパッチのマトリクスは、Oracle Metalinkhttp://metalink.oracle.comをアクセスし、Document ID 396906.1.を参照してください。 |
|
関連項目: Oracle Databaseソフトウェア・インストールで提供される$ORACLE_HOME/oracore/zoneinfo/timezdif.csvには、Oracle9i以上で変更されたタイム・ゾーンがすべてリストされています。また、アップグレード情報については、『Oracle Databaseアップグレード・ガイド』を参照してください。 |
バージョン3のタイム・ゾーン・ファイルに更新するため、Oracle Database 10gによってutltzuv2.sqlスクリプトが提供され、このスクリプトは指定したtimezdif.csvファイルに基づく外部の表を使用して、このスクリプトに関連したタイム・ゾーン・ファイルのバージョンと以前のバージョンに導入されたタイム・ゾーンの変更を説明します。たとえば、このデータにアクセスするためには、次の例のように、変更されたルールが有効となる年をクリックし、同等な外部表を作成します。$ORACLE_HOMEをOracleデータベース・ソフトウェアをインストールした実際のOracleホーム・ディレクトリに置き換えてください。
例4-6 timezdif.csvの問合せ内容に対する外部サンプル表
次の例では、$ORACLE_HOME/oracore/zoneinfo/timezdif.csvファイルの内容を使用する外部表を作成しています。
CONNECT / AS SYSDBA
CREATE DIRECTORY work_dir AS '$ORACLE_HOME/oracore/zoneinfo/';
GRANT READ ON DIRECTORY work_dir TO SCOTT;
CONNECT scott/tiger
CREATE TABLE TZONEDIFTAB (
VERSION NUMBER,
TIMEZONE_NAME VARCHAR2(64),
FROM_YEAR NUMBER,
TO_YEAR NUMBER
)
ORGANIZATION EXTERNAL
(TYPE oracle_loader
DEFAULT DIRECTORY work_dir
ACCESS PARAMETERS
(
RECORDS DELIMITED BY newline SKIP 3
FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY "'"
(
VERSION CHAR(5),
TIMEZONE_NAME CHAR(64),
FROM_YEAR CHAR(5),
TO_YEAR CHAR(5)
)
)
LOCATION ('timezdif.csv')
)
REJECT LIMIT UNLIMITED;
SELECT * FROM TZONEDIFTAB;
VERSION TIMEZONE_NAME FROM_YEAR TO_YEAR
---------- ---------------------------------------- ---------- ----------
3 Asia/Hong_Kong 1998 null
3 Asia/Tehran 2024 2027
...
データベースのタイム・ゾーンは、データベースの作成時に、CREATE DATABASE文のSET TIME_ZONE句を使用して設定します。データベースのタイム・ゾーンを設定しなければ、デフォルトでサーバーのオペレーティング・システムのタイム・ゾーンに設定されます。
タイム・ゾーンは、UTCからの絶対オフセットまたは指定のリージョンに設定できます。たとえば、タイム・ゾーンをUTCからのオフセットに設定するには、次のような文を使用します。
CREATE DATABASE db01 ... SET TIME_ZONE='-05:00';
有効なオフセットの範囲は-12:00から+14:00です。
タイム・ゾーンを指定のリージョンに設定するには、次のような文を使用します。
CREATE DATABASE db01 ... SET TIME_ZONE='Europe/London';
|
注意: データベースのタイム・ゾーンが関連するのは、TIMESTAMP WITH LOCAL TIME ZONE列のみです。データベース間でのデータ転送時にデータ変換を回避してパフォーマンスを改善するために、データベースのタイム・ゾーンはUTC（0:00）に設定することをお薦めします。これは、分散データベース、レプリケーションおよびエクスポートとインポートには特に重要です。 |
データベースのタイム・ゾーンは、ALTER DATABASE文のSET TIME_ZONE句を使用して変更できます。次に例を示します。
ALTER DATABASE SET TIME_ZONE='05:00'; ALTER DATABASE SET TIME_ZONE='Europe/London';
データベースにTIMESTAMP WITH LOCAL TIME ZONE列を含む表があり、その列にデータがあると、ALTER DATABASE SET TIME_ZONE文はエラーを返します。
変更は、データベースを停止して再起動するまで有効になりません。
次の問合せを入力すると、データベースのタイム・ゾーンを確認できます。
SELECT dbtimezone FROM DUAL;
デフォルトのセッション・タイム・ゾーンは、ORA_SDTZ環境変数を使用して設定できます。ユーザーがTIMESTAMP WITH LOCAL TIME ZONEデータを検索すると、そのユーザー・セッションのタイム・ゾーンで戻されます。セッションのタイム・ゾーンは、TIMESTAMP値がTIMESTAMP WITH TIME ZONEまたはTIMESTAMP WITH LOCAL TIME ZONEデータ型に変換される場合にも有効です。
ORA_SDTZ環境変数は次の値に設定できます。
UTCからの絶対オフセット（'-05:00'など）
タイム・ゾーン・リージョン名（'Europe/London'など）
UNIX環境（Cシェル）でORA_SDTZを設定するには、次のような文を使用します。
% setenv ORA_SDTZ 'OS_TZ' % setenv ORA_SDTZ 'DB_TZ' % setenv ORA_SDTZ '-05:00' % setenv ORA_SDTZ 'Europe/London'
ALTER SESSION文のSET TIME_ZONE句を使用して、特定のSQLセッションに対するタイム・ゾーンを変更できます。
TIME_ZONEは次の値に設定できます。
セッション開始時のデフォルトのローカル・タイム・ゾーン（local）
データベースのタイム・ゾーン（dbtimezone）
UTCからの絶対オフセット（'+10:00'など）
タイム・ゾーン・リージョン名（'Asia/Hong_Kong'など）
次のようなALTER SESSION文を使用します。
ALTER SESSION SET TIME_ZONE=local; ALTER SESSION SET TIME_ZONE=dbtimezone; ALTER SESSION SET TIME_ZONE='+10:00'; ALTER SESSION SET TIME_ZONE='Asia/Hong_Kong';
次の問合せを入力すると、現行のセッションのタイム・ゾーンを確認できます。
SELECT sessiontimezone FROM DUAL;
日時SQL式には、次のいずれかを使用できます。
日時列
日時値となる複合式
日時式には、AT LOCAL句またはAT TIME ZONE句を含めることができます。AT LOCAL句を含めると、結果は現在のセッションのタイム・ゾーンで戻されます。AT TIME ZONE句を含める場合は、その句で次のいずれかの設定を使用します。
タイム・ゾーン・オフセット: 文字列'(+|-)HH:MM'で、タイム・ゾーンをUTCからのオフセットとして指定します。たとえば、'-07:00'はUTCから7時間遅れのタイム・ゾーンを指定します。UTC時間が午前11時の場合、'-07:00'タイム・ゾーンの時間は午前4時です。
DBTIMEZONE: Oracleデータベースでは、データベース作成時に（明示的またはデフォルトで）設定されたデータベースのタイム・ゾーンを使用します。
SESSIONTIMEZONE: Oracleでは、デフォルトまたは最新のALTER SESSION文で設定されたセッションのタイム・ゾーンが使用されます。
タイム・ゾーン・リージョン名: Oracleデータベースでは、タイム・ゾーン・リージョン名が示すタイム・ゾーンの値を返します。たとえば、Asia/Hong_Kongを指定できます。
式: 式で有効なタイム・ゾーン書式の文字列が戻されると、Oracleデータベースはそのタイム・ゾーンの入力を返します。それ以外の場合、Oracleデータベースはエラーを返します。
次の例では、America/New_Yorkタイム・ゾーンの日時値をAmerica/Los_Angelesタイム・ゾーンの日時値に変換しています。
例4-7 他のタイム・ゾーンへの日時値の変換
SELECT FROM_TZ(CAST(TO_DATE('1999-12-01 11:00:00',
'YYYY-MM-DD HH:MI:SS') AS TIMESTAMP), 'America/New_York')
AT TIME ZONE 'America/Los_Angeles' "West Coast Time"
FROM DUAL;
West Coast Time
----------------------------------------------------------
01-DEC-99 08.00.00.000000 AM AMERICA/LOS_ANGELES
|
関連項目: 『Oracle Database SQLリファレンス』 |
Oracleデータベースは、指定のタイム・ゾーンで夏時間が有効かどうかを自動的に判別し、対応するローカル時間を返します。Oracleデータベースで夏時間が特定のタイム・ゾーンで有効かどうかを判別するには、通常、日時値で十分です。夏時間の開始期間または終了期間は境界事例です。たとえば、米国東部では、夏時間が有効になる時点で、時刻が午前1時59分59秒から午前3時0分0秒に変わります。午前2時0分0秒〜午前2時59分59秒の時間隔は存在しません。その時間隔に該当する値は無効です。夏時間の終了時には、時刻が午前2時0分0秒から午前1時0分1秒に変わります。午前1時0分1秒〜午前2時0分0秒の時間隔が繰り返されます。この時間隔に含まれる値は、2回発生するため不明確となります。
このような境界事例を解決するために、OracleデータベースではTZRおよびTZD書式要素を使用します。TZRは、日時入力文字列でのタイム・ゾーン・リージョンを表します。たとえば、'Australia/North'、'UTC'および'Singapore'などです。TZDは、夏時間情報を含むタイム・ゾーン・リージョンの略称を表します。たとえば、米国/太平洋標準時間の場合は'PST'、米国/太平洋夏時間の場合は'PDT'です。TZRおよびTZD書式要素に対して有効な値のリストを表示するには、V$TIMEZONE_NAMES動的パフォーマンス・ビューのTZNAME列とTZABBREV列を問い合せます。
TIMESTAMPデータ型はタイム・ゾーン値を受け入れず、夏時間は計算されません。
TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEデータ型は、次のように動作します。
タイム・ゾーン・リージョンが日時値に関連付けられている場合、データベース・サーバーではリージョンの夏時間規則が認識され、その規則が計算に使用されます。
夏時間を使用しないリージョンについては、夏時間は計算されません。
これ以降は、日時データ型の使用例を使用して説明します。この例ではglobal_orders表を使用します。この表には、TIMESTAMP データ型のorderdate1列とTIMESTAMP WITH TIME ZONEデータ型のorderdate2列が含まれています。global_orders表は次のように作成されます。
CREATE TABLE global_orders ( orderdate1 TIMESTAMP(0),
orderdate2 TIMESTAMP(0) WITH TIME ZONE);
INSERT INTO global_orders VALUES ( '28-OCT-00 11:24:54 PM',
'28-OCT-00 11:24:54 PM America/New_York');
例4-8 TIMESTAMP WITH TIME ZONEおよびTIMESTAMPを使用した夏時間計算の比較
SELECT orderdate1 + INTERVAL '8' HOUR, orderdate2 + INTERVAL '8' HOUR
FROM global_orders;
出力は次のようになります。
ORDERDATE1+INTERVAL'8'HOUR ORDERDATE2+INTERVAL'8'HOUR -------------------------- -------------------------- 29-OCT-00 07.24.54.000000 AM 29-OCT-00 06.24.54.000000 AM AMERICA/NEW_YORK
この例は、各列に8時間追加した場合の影響を示しています。この期間には、夏時間の境界（夏時間から標準時間への切替え）が含まれています。orderdate1列はTIMESTAMPデータ型で、夏時間情報は使用されないため、8時間内に発生する切替えにあわせた調整は実行されません。TIMESTAMP WITH TIME ZONEデータ型では切替えにあわせて調整されるため、orderdate2列はorderdate1列より1時間早い時刻を示します。
例4-9 TIMESTAMP WITH LOCAL TIME ZONEおよびTIMESTAMPを使用した夏時間計算の比較
TIMESTAMP WITH LOCAL TIME ZONEデータ型では、セッション環境にあわせて設定されたTIME_ZONEの値が使用されます。次の文は、TIME_ZONEセッション・パラメータの値を設定してglobal_orders表を作成します。global_orders表には、TIMESTAMPデータ型の1列とTIMESTAMP WITH LOCAL TIME ZONEデータ型の1列があります。
ALTER SESSION SET TIME_ZONE='America/New_York';
CREATE TABLE global_orders ( orderdate1 TIMESTAMP(0),
orderdate2 TIMESTAMP(0) WITH LOCAL TIME ZONE );
INSERT INTO global_orders VALUES ( '28-OCT-00 11:24:54 PM',
'28-OCT-00 11:24:54 PM' );
両方の列に8時間を追加します。
SELECT orderdate1 + INTERVAL '8' HOUR, orderdate2 + INTERVAL '8' HOUR FROM global_orders;
orderdate2の日時値にはタイム・ゾーン・リージョンが関連付けられているため、Oracleデータベース・サーバーではそのリージョンに夏時間規則が使用されます。そのため、出力は例4-8と同じになります。TIMESTAMPデータ型の場合は夏時間が計算されないため、2つの計算には1時間の時差があり、計算は夏時間境界にまたがっています。
例4-10 夏時間を使用しないリージョンについては計算されない夏時間
タイム・ゾーン・リージョンをUTCに設定します。UTCでは、夏時間は使用されません。
ALTER SESSION SET TIME_ZONE='UTC';
global_orders表を切り捨てます。
TRUNCATE TABLE global_orders;
global_orders表に値を挿入します。
INSERT INTO global_orders VALUES ( '28-OCT-00 11:24:54 PM',
TIMESTAMP '2000-10-28 23:24:54 ' );
各列に8時間を追加します。
SELECT orderdate1 + INTERVAL '8' HOUR, orderdate2 + INTERVAL '8' HOUR FROM global_orders;
出力は次のようになります。
ORDERDATE1+INTERVAL'8'HOUR ORDERDATE2+INTERVAL'8'HOUR -------------------------- --------------------------- 29-OCT-00 07.24.54.000000000 AM 29-OCT-00 07.24.54.000000000 AM UTC
UTCタイム・ゾーン・リージョンの場合は夏時間が計算されないため、時刻は同じです。
