Calendar クラス

定義

[Android.Runtime.Register("android/icu/util/Calendar", ApiSince=24, DoNotGenerateAcw=true)]
public abstract class Calendar : Java.Lang.Object, IDisposable, Java.IO.ISerializable, Java.Lang.ICloneable, Java.Lang.IComparable

[<Android.Runtime.Register("android/icu/util/Calendar", ApiSince=24, DoNotGenerateAcw=true)>]
type Calendar = class
    inherit Object
    interface ISerializable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface ICloneable
    interface IComparable

継承

Object

JavaObject

Object

Calendar

派生

Android.Icu.Util.CECalendar

Android.Icu.Util.ChineseCalendar

Android.Icu.Util.GregorianCalendar

Android.Icu.Util.HebrewCalendar

Android.Icu.Util.IndianCalendar

その他…

属性

RegisterAttribute

実装

IJavaObject IJavaPeerable ISerializable ICloneable IComparable IDisposable

注釈

<strong>[icu enhancement]</strong> ICU の java.util.Calendar の置き換え。 ICU に固有のメソッド、フィールド、およびその他の機能には、"<strong>[icu]</strong>' というラベルが付けられます。

Calendar は、 Date オブジェクトと、 YEAR、 MONTH、 DAY、 HOUR などの整数フィールドのセットの間で変換するための抽象基本クラスです。 (Date オブジェクトは、ミリ秒単位の特定の時間を表します。Date クラスの詳細については、Dateを参照してください)。

Calendarのサブクラスは、特定のカレンダー システムのルールに従ってDateを解釈します。 ICU4J には、さまざまな国際カレンダー システムを実装するサブクラスがいくつか含まれています。

他のロケール依存クラスと同様に、 Calendar は、この型の一般的に有用なオブジェクトを取得するためのクラス メソッド ( getInstance) を提供します。 Calendar's getInstance メソッドは、ロケールに適した型のカレンダーを返します。時刻フィールドは現在の日時で初期化されています: <blockquote>

Calendar rightNow = Calendar.getInstance()

</blockquote>

ULocaleによってgetInstanceが使用されると、その 'calendar' タグと値が存在する場合は取得されます。 認識された値を指定すると、カレンダーが提供され、必要に応じて構成されます。 現在認識されているタグは、"仏教"、"中国語"、"コプト"、"エチオピック"、"グレゴリオ暦"、"ヘブライ語"、"イスラム"、"イスラム的"、"イスラム市民"、"日本語"、"roc" です。 例: <blockquote>

Calendar cal = Calendar.getInstance(new ULocale("en_US@calendar=japanese"));

</blockquote> は、JapaneseCalendar のインスタンスを返します (最初の週の最小日数、週の開始曜日、および cetera のen_US規則を使用)。

Calendar オブジェクトは、特定の言語およびカレンダー スタイル (日本語グレゴリオ暦、Japanese-Traditionalなど) の日付と時刻の書式設定を実装するために必要なすべての時間フィールド値を生成できます。 Calendar は、特定のフィールドによって返される値の範囲とその意味を定義します。 たとえば、年の最初の月には、すべてのカレンダーの値 MONTH == JANUARY があります。 その他の値は、 ERA や YEARなど、具象サブクラスによって定義されます。 詳細については、個々のフィールドのドキュメントとサブクラスのドキュメントを参照してください。

Calendarが <em>lenient</em> の場合、生成されるフィールド値よりも広い範囲のフィールド値を受け入れます。 たとえば、GregorianCalendarMONTH == == 32 を 2 月 1 日として解釈JANUARY、DAY_OF_MONTHが緩やかです。 非 lenient GregorianCalendar は、範囲外のフィールド設定が指定されると例外をスローします。 カレンダーは、戻り値のフィールド値を get()で再計算すると、それらを正規化します。 たとえば、 GregorianCalendar では、常に 1 から月の長さの DAY_OF_MONTH 値が生成されます。

Calendar は、2 つのパラメーターを使用してロケール固有の 7 日間の週を定義します。週の最初の日と最初の週の最小日数 (1 から 7)。 これらの数値は、 Calendar が構築されるときにロケール リソース データから取得されます。 API を使用して明示的に指定することもできます。

WEEK_OF_MONTHまたはWEEK_OF_YEARフィールドを設定または取得する場合、Calendarは、月または年の最初の週を参照ポイントとして決定する必要があります。 月または年の最初の週は、 getFirstDayOfWeek() から始まり、その月または年の少なくとも getMinimalDaysInFirstWeek() 日を含む最も早い 7 日間として定義されます。 週番号 ..., -1, 0 は最初の週より前です。週番号は 2、3 です,...それに従ってください。 get()によって返される正規化された番号は異なる場合があることに注意してください。 たとえば、特定の Calendar サブクラスは、1 年の第 1 週の前の週を前年の週 <em>n</em> として指定できます。

時間フィールドから Date を計算する場合は、特別な状況が発生する可能性があります。 Date を計算するには情報が不十分な場合があります (たとえば、年と月は 1 日のみ)、一貫性のない情報 ("火曜日、7 月 15 日、1996 年 7 月 15 日" など) が存在する可能性があります。つまり、1996 年 7 月 15 日は、タイム ゾーンの切り替えのために入力時刻があいまいな場合があります。

<strong>Insufficient information.</strong> 予定表では、既定の情報を使用して、不足しているフィールドを指定します。 これはカレンダーによって異なる場合があります。グレゴリオ暦の場合、フィールドの既定値はエポックの開始と同じです。つまり、YEAR = 1970、MONTH = JANUARY、DATE = 1 などです。

<strong>Inconsistent information.</strong> フィールドが競合する場合、カレンダーは最近設定したフィールドを優先します。 たとえば、日を決定するときに、カレンダーは次のいずれかのフィールドの組み合わせを検索します。 最後に設定された 1 つのフィールドによって決定される最新の組み合わせが使用されます。

<blockquote>

MONTH + DAY_OF_MONTH
            MONTH + WEEK_OF_MONTH + DAY_OF_WEEK
            MONTH + DAY_OF_WEEK_IN_MONTH + DAY_OF_WEEK
            DAY_OF_YEAR
            DAY_OF_WEEK + WEEK_OF_YEAR

</blockquote>

時刻の場合:

<blockquote>

HOUR_OF_DAY
            AM_PM + HOUR

</blockquote>

<strong>Ambiguous Wall Clock Time.</strong> UTC からの時間オフセットが変更されると、遷移の前後にあいまいなタイム スロットが生成されます。 たとえば、多くの米国の場所では夏時間が観察されます。 米国の夏時間に切り替えた日付では、壁掛け時計の時刻が午前 12 時 59 分 (標準) から午前 2 時 (夏時間) にジャンプします。 したがって、1:00 AM から 1:59 AM までの壁時計の時刻は日付に存在しません。 入力壁の時間がこの不足しているタイム スロットに分類されると、ICU カレンダーは既定で遷移前の UTC オフセットを使用して時刻を解決します。 この例では、午前 1 時 30 分は午前 1 時 30 分 (存在しない) と解釈されるため、最終的な結果は午前 2 時 30 分の夏時間になります。

標準時刻に戻す日付では、壁掛け時計の時刻は午前 2 時 00 分に 1 時間戻されます。 したがって、1:00 AM から 1:59 AM までのウォール クロック時間は 2 回発生します。 この場合、ICU カレンダーは、既定で遷移後の UTC オフセットを使用して時刻を解決します。 たとえば、日付の午前 1 時 30 分は、標準時の午前 1 時 30 分として解決されます。

あいまいな壁時計の時間解決動作は、カレンダー API #setRepeatedWallTimeOption(int) および #setSkippedWallTimeOption(int)によってカスタマイズできます。 これらのメソッドは、ICU 49 以降のバージョンで使用できます。

<strong>Note:</strong> 一部のグレゴリオ暦以外のカレンダーでは、完全なあいまいさを解消するために異なるフィールドが必要になる場合があります。 たとえば、アラビア暦の履歴カレンダーの完全な仕様には、年、月、日 <em>および</em> 曜日が必要な場合があります。

<strong>Note:</strong><ol><li> 24:00:00 は次の方法で解決され、特定の単一時刻の解釈に特定のあいまいさが生じ得ます。 つまり、1969 年 12 月 31 日 23:59 >1970 年 1 月 1 日 24:00 >1970 年 1 月 1 日 24:01:00

<li> 歴史的には正確ではありませんが、午前 0 時も "am" に属し、正午は "pm" に属しているため、同じ日の午前 12 時 (午前 0 時) > 午後 12 時 11 分、午後 12 時 00 分 > 午後 12:01 </ol>

日付または時刻の書式指定文字列は、実行時にユーザーが変更またはオーバーライドできる必要があるため、カレンダーの定義の一部ではありません。 DateFormatを使用して日付を書式設定します。

<strong>Field 操作メソッド</strong>

Calendar フィールドは、 set()、 add()、 roll()の 3 つの方法を使用して変更できます。

<strong>set(f, value)</strong> フィールドの f が valueに変更されます。 さらに、フィールド f が変更されたことを示す内部メンバー変数を設定します。 フィールド f は直ちに変更されますが、 get()、 getTime()、または getTimeInMillis() の次回の呼び出しが行われるまで、カレンダーのミリ秒は再計算されません。 したがって、 set() に対する複数の呼び出しでは、複数の不要な計算はトリガーされません。 set()を使用してフィールドを変更した結果、フィールド、フィールド値、カレンダー システムによっては、他のフィールドも変更される可能性があります。 また、フィールドが再計算された後、 get(f) は必ずしも value を返すとは限りません。 詳細は、具象カレンダー クラスによって決定されます。

<em>Example</em>: 最初に 1999 年 8 月 31 日に設定された GregorianCalendar について考えてみます。 set(Calendar.MONTH, Calendar.SEPTEMBER)を呼び出すと、カレンダーが 1999 年 9 月 31 日に設定されます。 これは、 getTime()呼び出された場合に 1999 年 10 月 1 日に解決される一時的な内部表現です。 ただし、set(Calendar.DAY_OF_MONTH, 30)の呼び出しの前にgetTime()を呼び出すと、1999 年 9 月 30 日にカレンダーが設定されます。これは、set()自体の後に再計算が行われないためです。

<strong>add(f, delta)</strong> はフィールド deltaにfを追加します。 これは、次の 2 つの調整を使用して set(f, get(f) + delta) を呼び出すことと同じです。

<blockquote>

<strong>ルール 1</strong> を追加します。 呼び出し後にfフィールドの値から、呼び出しがfされる前のフィールド deltaの値を引いた値。フィールド fで発生したすべてのオーバーフローを剰余します。 オーバーフローは、フィールド値がその範囲を超えた場合に発生し、その結果、次に大きいフィールドがインクリメントまたはデクリメントされ、フィールド値がその範囲に調整されます。

<strong>ルール 2</strong> を追加します。 小さいフィールドが不変であると予想される場合は 、 フィールド f が変更された後に最小値または最大値が変更されたため、以前の値と等しくすることはできません。その後、その値は、予想される値にできるだけ近くなるように調整されます。 フィールドが小さいと、時間の単位が小さくなります。 HOUR は、 DAY_OF_MONTHよりも小さいフィールドです。 不変であるとは予想されない小さいフィールドに対して調整は行われません。 カレンダー システムは、不変と予想されるフィールドを決定します。

</blockquote>

さらに、 set()とは異なり、 add() はカレンダーのミリ秒とすべてのフィールドの即時再計算を強制します。

<em>Example</em>: 最初に 1999 年 8 月 31 日に設定された GregorianCalendar について考えてみます。 add(Calendar.MONTH, 13)を呼び出すと、カレンダーが 2000 年 9 月 30 日に設定されます。 <strong>ルール 1</strong> を追加すると、 MONTH フィールドが 9 月に設定されます。13 か月を 8 月に追加すると、次の年の 9 月が与えられます。 DAY_OF_MONTH GregorianCalendarでは 9 月に 31 にすることはできません。そのため、<strong>追加規則 2</strong> はDAY_OF_MONTHを 30 (可能な限り最も近い値) に設定します。 小さいフィールドですが、 DAY_OF_WEEK はルール 2 では調整されません。これは、 GregorianCalendarで月が変わると変更される可能性があるためです。

<strong>roll(f, delta)</strong> では、大きなフィールドを変更せずにフィールド deltaにfが追加されます。 これは、次の調整で add(f, delta) を呼び出すことと同じです。

<blockquote>

<strong>Roll rule</strong>。 大きいフィールドは、呼び出し後も変更されません。 フィールドが大きいほど、時間の単位が大きくなります。 DAY_OF_MONTH は、 HOURよりも大きいフィールドです。

</blockquote>

<em>Example</em>: 最初に 1999 年 8 月 31 日に設定された GregorianCalendar について考えてみます。 roll(Calendar.MONTH, 8)を呼び出すと、カレンダーが 1999 年 4 月 30 日<></強>に設定されます。 ルール 1 を追加すると、 MONTH フィールドが 4 月に設定されます。 GregorianCalendarを使用すると、4 月のDAY_OF_MONTHを 31 にすることはできません。 ルール 2 を追加すると、可能な最も近い値 30 に設定されます。 最後に、 <strong>roll ルール</strong> は 1999 年の YEAR フィールド値を保持します。

<em>Example</em>: 最初に 1999 年 6 月 6 日 (日) に設定された GregorianCalendar について考えてみます。 roll(Calendar.WEEK_OF_MONTH, -1)を呼び出すと、カレンダーは 1999 年 6 月 1 日火曜日に設定されますが、add(Calendar.WEEK_OF_MONTH, -1)呼び出しは 1999 年 5 月 30 日 (日曜日) に設定されます。 これは、ロール ルールによって追加の制約が適用されるためです。 MONTH は、 WEEK_OF_MONTH のロール時に変更しないでください。 ルール 1 を追加すると、結果の日付は 6 月 1 日 (火) から 6 月 5 日 (土曜日) の間である必要があります。 ルール 2 を追加すると、DAY_OF_WEEKを変更するときの不変のWEEK_OF_MONTHは、可能な最も近い値である火曜日 (日曜日は週の最初の日) に設定されます。

<strong>Usage モデル</strong>。 add()とroll()の動作を動機付けるために、月、日、年のインクリメント ボタンとデクリメント ボタンを持つユーザー インターフェイス コンポーネントと、基になるGregorianCalendarを検討します。 インターフェイスが 1999 年 1 月 31 日を読み取り、ユーザーが月単位のボタンを押した場合、何を読む必要がありますか? 基になる実装で set() を使用している場合は、1999 年 3 月 3 日を読み取る可能性があります。 より良い結果は、1999 年 2 月 28 日になります。 さらに、ユーザーがもう一度月単位のボタンを押した場合は、1999 年 3 月 28 日ではなく、1999 年 3 月 31 日を読み取る必要があります。 元の日付を保存し、 add() または roll()を使用することで、大きなフィールドに影響を与える必要があるかどうかに応じて、ほとんどのユーザーが直感的に期待するようにユーザー インターフェイスを動作させることができます。

<b>Note:</b>#roll rollのフィールドに対して算術演算を直接実行するのではなく、常に#add addとCalendarを使用する必要があります。 Calendarサブクラスには、非線形動作を持つフィールド (たとえば、閏年以外の月や日が不足しているなど) がある可能性があります。 サブクラスの add メソッドと roll メソッドはこれを考慮しますが、単純な算術操作では無効な結果が得られます。

<big><big><b>Calendar Architecture in ICU4J</b></big></big>

最近、サブクラス化をより適切にサポートするために、 Calendar の実装が大幅に変更されました。 元の Calendar クラスはサブクラス化をサポートするように設計されましたが、実装されたサブクラスは 1 つだけ GregorianCalendar。 BuddhistCalendar、ChineseCalendar、HebrewCalendar、IslamicCalendar、JapaneseCalendarなど、複数の新しいカレンダー サブクラスの実装により、サブクラス化 API が徹底的に作り直されました。 このセクションでは、新しいサブクラス化 API と、 android.icu.util.Calendar が java.util.Calendarと異なるその他の方法について詳しく説明します。

<big><b>Changes</b></big>

クラシック Calendar アーキテクチャと新しいアーキテクチャの間の変更の概要。

<ul>

<li>fields[]配列がprivateの代わりにprotectedされるようになりました。 サブクラスは、 #internalSet メソッドと #internalGetメソッドを使用してアクセスする必要があります。 <b>Motivation:</b> サブクラスはデータ メンバーに直接アクセスしないでください。</li>

<li>time長い単語がprivateではなくprotectedされるようになりました。 サブクラスはメソッド #internalGetTimeInMillisを使用してアクセスできます。これは更新を引き起こしません。 <b>Motivation:</b> サブクラスはデータ メンバーに直接アクセスしないでください。</li>

<li>サブクラスの責任範囲が大幅に削減されました。 Calendar基底クラスには、可能な限り多くの機能が実装されています。 その結果、 Calendarをサブクラス化する方がはるかに簡単です。 <b>Motivation:</b> サブクラスは、共通コードを再実装する必要はありません。 一部の動作は、カレンダー システム間で共通です。週関連のフィールドと時刻フィールドの定義と動作、多くのフィールドの算術 (#add(int, int) add と #roll(int, int) roll) の動作、フィールド検証 system.</li>

<li>サブクラス化 API は完全に再設計されました。</li>

<li>Calendar基底クラスには、サブクラスが使用できるグレゴリオ暦のアルゴリズムサポートがいくつか含まれています (具体的には#handleComputeFields)。 サブクラスは、 getGregorianXxx() メソッドを使用して事前計算された値を取得できます。 <b>Motivation:</b> これは、一貫したタイム ゾーンの動作を実装するためにすべての Calendar サブクラスで必要であり、グレゴリオ暦から派生したシステムでは、既に計算されたデータを使用できます。</li>

<li>FIELD_COUNT定数が削除されました。 #getFieldCount を使用してください。 さらに、サブクラスが追加のフィールドを定義できるように、フレームワーク API が追加されました。 <b>Motivation: </b>カレンダー システム全体でフィールドの数が一定ではありません。</li>

<li>処理日の範囲は、+/- ~300,000,000 年から +/- ~5,000,000 年に絞り込まれています。 実際には、これはクライアントに影響を与えるべきではありません。 ただし、クライアント コードは、 Date(Long.MIN_VALUE) や Date(Long.MAX_VALUE)などの日付で適切に動作する結果を保証できないことを意味します。 代わりに、保護 Calendar 定数を使用する必要があります。 <b>Motivation:</b>#JULIAN_DAY フィールドを追加する場合、ユリウス日の数値は 32 ビットの intに制限する必要があります。 これにより、サポートされる範囲全体が制限されます。 さらに、サポートされている範囲を制限すると、 Long.MIN_VALUE および Long.MAX_VALUE.< 付近のミリスでの算術オーバーフローに対応するために使用された特殊なケース コードが削除され、計算が簡略化されます。/li>

<li>新しいフィールドが実装されています。 #JULIAN_DAY は、日付の単一フィールドの指定を定義します。 #MILLISECONDS_IN_DAY では、壁時間の単一フィールドの仕様が定義されます。 #DOW_LOCAL ローカライズされた曜日と週単位の動作を実装 #YEAR_WOY 。</li>

<li>Subclasses は、 Calendar.< で定義されている保護されたミリ秒の定数にアクセスできます/li>

<li>new API が追加され、 DateFormat.< のカレンダー固有のサブクラスがサポートされました/li>

<li>様々な国際カレンダーシステムを表すSeveralサブクラスが実装されています.</li>

</ul>

<big><b>Subclass API</b></big>

元の Calendar API は、単一のサブクラス ( GregorianCalendar) を実装した経験に基づいていました。 その結果、サブクラス化するキンクはすべてうまくいきっていません。新しいサブクラス化 API は、実装された複数のサブクラスに基づいて改良されました。 これには、オーバーライドする必要があるメソッドとサブクラスが呼び出すメソッドが含まれます。 サブクラスは、 fields と stampに直接アクセスできなくなりました。 代わりに、これらにアクセスするための新しい API があります。 サブクラスは、保護されたフレームワーク メソッドを使用して fields 配列を割り当てることができます。これにより、サブクラスは追加のフィールドを指定できます。

より多くの機能が基底クラスに移動されました。 基底クラスには、グレゴリオ暦をサポートする計算機械の多くが含まれるようになりました。 これは2つのことに基づいています:(1)多くの暦はグレゴリオ暦(仏教暦や日本の帝国暦など)に基づいています。 (2) <em>All</em> カレンダーでは、タイムゾーンの計算を処理するために基本的なグレゴリオ暦のサポートが必要です。

一般的な計算が Calendarに移動されました。 サブクラスは、週関連フィールドと時刻関連フィールドを計算しなくなりました。 これらは通常、基本クラスによってすべてのカレンダーに対して処理されます。

<b>時間 => フィールドのサブクラス計算</b>

#ERA、#YEAR、#EXTENDED_YEAR、#MONTH、#DAY_OF_MONTH、および#DAY_OF_YEARの各フィールドは、ユリウス日に基づいてサブクラスによって計算されます。 その他のすべてのフィールドは、 Calendarによって計算されます。

<ul>

<li>Subclasses は、#handleComputeFields フィールドの値に基づいて、#ERA、#YEAR、#EXTENDED_YEAR、#MONTH、#DAY_OF_MONTH、および#DAY_OF_YEARフィールドを計算する#JULIAN_DAYを実装する必要があります。 Calendarで定義されていないカレンダー固有のフィールドがある場合は、それらのフィールドも計算する必要があります。 サブクラスが計算する必要がある唯一のフィールドは次のとおりです。 その他のすべてのフィールドは基底クラスによって計算されるため、時間と週のフィールドはすべてのカレンダーで一貫した方法で動作します。 Calendarのこのメソッドの既定のバージョンでは、プロレプティック グレゴリオ暦が実装されています。 このメソッド内では、サブクラスは getGregorianXxx() を呼び出して、グレゴリオ暦の暦月、月の日、および指定された date.< の拡張年を取得できます。/li>

</ul>

<b>フィールド => 時間のサブクラス計算</b>

ほとんどのフィールド値の解釈は、 Calendarによって完全に処理されます。 Calendar は、設定されるフィールド、設定されていないフィールド、最近設定されるフィールドなどを決定します。 さらに、 Calendar は時間フィールドからの時間の計算を処理し、週関連のフィールドを処理します。 サブクラスが行う必要があるのは、年フィールドに基づいて拡張年を決定することだけです。その後、拡張年と月を指定すると、ユリウス日番号を返す必要があります。

<ul>

<li>Subclasses は、#handleGetExtendedYear、#YEAR、カレンダー システムが 1 年を超えるフィールド (#EXTENDED_YEAR.#ERA など) に基づいて、このカレンダー システムの延長年を返す<を実装する必要があります/li>

<li>Subclasses は、1 か月と延長年に関連付けられたユリウス日番号を返す #handleComputeMonthStart を実装する必要があります。 これは、月の最初の日の前日のユリウス日番号です。 月番号は 0 から始まります。 この計算は、どのフィールド値にも依存しないでください。</li>

</ul>

<b>その他のメソッド</b>

<ul>

<li>Subclasses は、特定の延長年の特定の月の日数を返す #handleGetMonthLength を実装する必要があります。 月の数値は、常に 0 から始まります。</li>

<li>Subclasses は、指定された延長年の日数を返す #handleGetYearLength を実装する必要があります。 このメソッドは、 computeWeekFields が #WEEK_OF_YEAR と #YEAR_WOY fields を計算するために使用されます。</li>

<li>Subclasses は、#handleGetLimitの値に応じて、フィールドの保護された値を返すlimitTypeを実装する必要があります。 このメソッドは、フィールド #ERA、 #YEAR、 #MONTH、 #WEEK_OF_YEAR、 #WEEK_OF_MONTH、 #DAY_OF_MONTH、 #DAY_OF_YEAR、 #DAY_OF_WEEK_IN_MONTH、 #YEAR_WOY、および #EXTENDED_YEARのみを処理する必要があります。 その他のフィールドは (カレンダー システムに関して) 不変であり、基底クラスによって処理されます。</li>

<li>サブクラスは、サブクラス固有のフィールドをチェックするために #validateField をオーバーライドできます。 フィールドの値が範囲外の場合、メソッドは IllegalArgumentExceptionをスローする必要があります。 このメソッドは super.validateField(field) を呼び出して、フィールドを汎用的な方法で処理し、 getMinimum(field)..getMaximum(field).< の範囲と比較することができます。/li>

<li>オプションとして、サブクラスは #handleCreateFields をオーバーライドして、カレンダーのフィールドを保持するのに十分な大きさの int[] 配列を作成できます。 これは、カレンダーが Calendarで定義されたフィールド以外の追加フィールドを定義する場合にのみ必要です。 結果の長さは、基本フィールド数と最大フィールド数の間である必要があります。</li>

<li>サブクラスは #handleGetDateFormat をオーバーライドして、このカレンダーに適した DateFormat を作成できます。 これは、カレンダー サブクラスがフィールドの使用を再定義する (たとえば、 #ERA フィールドをシンボリック フィールドから数値フィールドに変更する) か、追加のフィールドを定義する場合にのみ必要です。</li>

<li>サブクラスは、不連続なフィールドを処理するために #roll roll と #add add をオーバーライドできます。 たとえば、ヘブライ語のカレンダーでは、月 >Adar I>閏年でのみ発生します。それ以外の年では、カレンダーは Shevat (月 #4) から Adar (月 #6) にジャンプします。 HebrewCalendar#add HebrewCalendar.addメソッドとHebrewCalendar#roll HebrewCalendar.rollメソッドはこれを考慮に入れ、Shevat に 1 か月を追加すると、閏年以外の適切な結果 (Adar) が得られます。 保護されたユーティリティ メソッド #pinField pinField は、多くの場合、これら 2 つのメソッドを実装するときに役立ちます。 </li>

</ul>

<big><b>正規化された動作</b></big>

特定のフィールドの動作は、すべてのカレンダー システムで一貫性が保たれ、 Calendarで実装されています。

<ul>

<li>Time は正規化されます。 一部のカレンダー システムは日の入りまたは他の時刻に切り替わりますが、すべての ICU4J カレンダーは、 <em>local zone midnight</em> の日の間で切り替わります。 これにより、ICU4Jは Calendar の時間計算を一元化し、カレンダーシステム間の基本的な対応を維持することができます。 影響を受けるフィールド: #AM_PM、 #HOUR、 #HOUR_OF_DAY、 #MINUTE、 #SECOND、 #MILLISECOND、 #ZONE_OFFSET、 #DST_OFFSET.</li>

<li>DST 動作は正規化されます。 夏時間の動作はすべてのカレンダー システムで同じように計算され、GregorianCalendar、#YEAR、#MONTHなど、複数の#DAY_OF_MONTH フィールドの値に依存します。 その結果、グレゴリオ暦以外のカレンダー システムの場合でも、 Calendar は常にこれらのフィールドを計算します。 これらのフィールドはサブクラスで使用できます。</li>

<li>Weeks は正規化されます。 ロケールは週を異なる方法で定義しますが、開始日と 1 か月または 1 年の週番号の指定に関しては、すべて共通のメカニズムを使用します。 さらに、曜日は、履歴全体にわたってシンプルで一貫した定義を持っています。 たとえば、グレゴリオ暦では最初に定められたときに不連続が発生しましたが、曜日は中断されませんでした。 このため、 #DAY_OF_WEEK、 WEEK_OF_YEAR, WEEK_OF_MONTH、 #DAY_OF_WEEK_IN_MONTH、 #DOW_LOCAL、 #YEAR_WOY のフィールドはすべて、サブクラスによって計算される #EXTENDED_YEAR、 #DAY_OF_YEAR、 #MONTH、および #DAY_OF_MONTHに基づいて、基底クラスで一貫した方法で計算されます</li>

</ul>

<big><b>サポート範囲</b></big>

Calendarの許容範囲が狭まっている。 GregorianCalendar は、 Long.MIN_VALUE から Long.MAX_VALUE までのミリ秒の値を持つ日付の範囲をサポートするために使用されます。 これにより、パフォーマンスが低下する厄介な構造 (ハック) が導入されました。 また、境界で非一様な動作も導入されました。 新しいCalendar プロトコルでは、ユリウス日の数が-0x7F000000に+0x7F000000されたものとして、サポート可能な日付の最大範囲を指定します。 これは、約 5,800,000 BCE から約 5,800,000 CE までの年に相当します。 プログラマは、 Calendar で保護された定数を使用して、非常に早い日付または非常に遅い日付を指定する必要があります。

<big><b>General notes</b></big>

<ul>

<li>Calendars の実装は <em>proleptic</em>です。 たとえば、グレゴリオ暦は 16 世紀まで制定されていなくても、 GregorianCalendar クラスはカレンダー システムを時間的に後方に拡張することで、カレンダーの歴史的開始前の日付をサポートします。 同様に、 HebrewCalendar はエポックの開始前に 0 年と負の年に後方に拡張されます。 日付がカレンダー システムの開始履歴の前にあるため、サブクラスは例外をスローしません。 代わりに、#handleGetLimit、#YEARなどのフィールドに適切な制限を返す#ERAを実装します。 次に、カレンダーが lenient に設定されていない場合、範囲外のフィールド値によって exception.< がトリガーされます。/li>

<li>Calendar システム サブクラスは、 <em>extended year</em> を計算します。 これは、 #YEAR フィールドとは異なり、ゼロと負の値を含むすべての整数値の範囲を指定し、 #YEAR フィールドとすべての大きなフィールドの情報をカプセル化します。 したがって、グレゴリオ暦では、 #EXTENDED_YEAR は ERA==AD ? YEAR : 1-YEARとして計算されます。 もう 1 つの例は、年 (KUN) と入れ子になった年 (KATUN と BAKTUN) を持つマヤの長いカウントです。 マヤ #EXTENDED_YEAR は TUN + 20 * (KATUN + 20 * BAKTUN)として計算されます。 Calendar基底クラスは、#EXTENDED_YEAR フィールドを使用して週関連のフィールドを計算します。</li>

</ul>

Javaドキュメント。

このページの一部は、によって作成および共有され、に記載されている条件に従って使用される作業に基づく変更です。