日付/時刻マスクとフォーマット指定子

デフォルトのマスクは yyyyMM です。

  yyyyyyMM
  yyyyyy
  MM

  ddHHmmssffffff
  HHmmssff
  mmss
  HHmm

  // 無効
  ddmmssffffff 
  HHssff

デフォルトのマスクは yyyyMMddHHmmss です。

構文解析フォーマットの規則は、表示フォーマットの規則と同じであり、例外については以下の規則として示します。

ユーザー独自のフォーマット・パターンは、日付または時刻の構成要素を示す文字を使用して作成します。 日付または時刻のコンポーネントとしてテキストを構文解析することなく、日付/時刻ストリングに文字を組み込むには、その文字 (単数または複数) を単一引用符で囲んでください。 日付、時刻、またはタイム・スタンプで単一引用符を表示する場合は、単一引用符を 2 個使用します。

次の表では、パターン内の文字およびその値をリストしています。

パターン内で連続して使用される複数の同一文字によって、EGL がストリング内で対応する数字、文字、または両方を解析する方法が決まります。 解釈は、文字のタイプによって異なり、またパターンがフォーマット設定または構文解析のいずれに使用されるかに応じても異なります。次のリスト は、文字の型、およびこれらの文字の数量の違いが、それらの解釈方法にどのように影響するかを示しています。

テキスト

出力設定の場合、文字数が 4 文字より多い場合は、フル書式が使用されます。4 文字以上のときは、可能な場合、略語が使用されます。 構文解析では、パターン文字の数に関係なく、両方の書式が受け入れられます。

数値

出力の場合、パターン文字の数は、最小桁数を表します。 数字を指定の長さに短くする場合は、ゼロが追加されます。 構文解析では、2 つの隣接するフィールドを分離するために必要でないかぎり、パターン文字の数は無視されます。

年

フォーマット設定の場合、パターン文字の数が 2 であれば、年が 2 桁に切り捨てられます。 その他の場合は、年は数値型として解釈されます。

構文解析では、パターン文字の数が 2 でない場合、桁数に関係なく、年は文字どおりに解釈されます。 例えば、パターン MM/dd/yyyy に値 01/11/12 を割り当てると、January 11, 12 A.D. と解析されます。同じパターンに値 01/02/3 または 01/02/0003 を割り当てると、January 2, 3 A.D. と解析されます。同様に、同じパターンに値 01/02/-3 を割り当てると、January 2, 4 B.C. と解析されます。

構文解析では、パターンが yy の場合、パーサーにより、現在の年を基準としてフル年が判別されます。 パーサーは、2 桁で表された年を、処理時点の 80 年前から 20 年後以内と想定します。例えば、現在の年が 2007 年である場合、 パターン MM/dd/yy に値 01/11/12 を割り当てると 2012 年 1 月 11 日と解析し、 値 05/04/64 を割り当てると 1964 年 5 月 4 日と解析します。

月

文字パターンの数が 3 以上の場合、月はテキスト型として解釈されます。その他の場合は、年は数値型として解釈されます。

ミリ秒

INTERVAL または TIMESTAMP 変数をフォーマットするには、SSSS を使用します。 (変数を宣言する場合は、代わりに ffff を使用します。) 以下に例を示します。

t TIMESTAMP( "ssffff" );
s STRING = StrLib.formatTimestamp( t, "ssSSSS" );

一般タイム・ゾーン

一般タイム・ゾーンは、名前が付けられている場合、テキスト型として解釈されます。GMT オフセット値を表すタイム・ゾーンの場合、次の構文規則が使用されます。

GMTOffsetTimeZone = GMT 符号 時間 分

符号

+ または -

時間

0 から 23 までの 1 桁または 2 桁の数値。書式はロケールに依存せず、 ユニコード規格の基本ローマ字ブロックから取得する必要があります。

分

00 から 59 までの 2 桁の数値。書式はロケールに依存せず、 ユニコード規格の基本ローマ字ブロックから取得する必要があります。

構文解析では、RFC 822 タイム・ゾーンも許容されます。

RFC 822 タイム・ゾーン

フォーマット設定には、RFC 822 4 桁タイム・ゾーン形式が使用されます。

RFC822TimeZone = 符号 TwoDigitHours 分

TwoDigitHours は、00 から 23 までの 2 桁の数値でなければなりません。 その他の定義は、一般タイム・ゾーンと同じです。

構文解析では、一般タイム・ゾーンも許容されます。

世紀

次の計算結果を表す数値型として表示されます。4 桁の西暦年を 100 で除算し、 余りは無視されます。

次の表では、米国のロケールで解釈される日付と時刻パターンのサンプルの一部を記載しています。すべて同じ日付、4 July、2001、午後 12:08:56、太平洋夏時間 (Pacific Daylight Time) を使用しています。

「日付/時刻」フォーマット指定子には、カレンダー指定子を組み込むこともできます。 これらの指定子は EGL が入力する日付ストリングの構文解析、 または出力する日付ストリングのフォーマットに使用するカレンダー・システムを示します。EGL は、指定したカレンダーや、DATE、TIME、TIMESTAMP 変数の内部値の、ストリング・データ間における変換を実行します。

各種のカレンダー・システムでローカライズされた日付ストリングは、他のロケールでは出力できない場合があるため、この問題は複雑になりがちです。 カレンダーが異なると、使用する年号指定子のほか、年の番号付けの起点も異なるので、多くの場合、特定のローカライズされた環境でしか正しく表示されません。 例えば、和暦の元号日付システムは、旧形式のユリウス暦 (グレゴリオ暦より数日遅れ) 同様、日本の天皇の治世年により決まります。

myDate DATE;
myJapaneseDate STRING;

strLib.defaultDateFormat = "Gryyyy/MM/dd";
myDate = "1912/08/13";
myJapaneseDate = formatDate(myDate,"JaGyy/MM/dd");

以下の表は、グレゴリオ暦の日付を上で示した日本元号形式に変換した例を示しています。 大括弧内の名前は、所定の日本元号を示す日本語の文字 (4 つの 2 バイト) を表します。

EGL は、Java™ バージョンの International Components for Unicode ライブラリー (ICU4J) を使用して、入力および表示に必要な日付変換を行っています。 しかし、EGL は、常に日付をグレゴリオ暦形式の 8 桁を使用して保存します。 つまり、タイ語のアプリケーションでは仏教暦の日付が必要になりますが、 EGL では変換に ICU4J を使用することで、その日付を 8 桁のグレゴリオ暦形式で保存しているということです。 アプリケーションは、使用するパターンの整合性を保つため、この処理はプログラマーおよびユーザーの両方に対し非表示のままになっています。