IChronoLocalDate 介面

定義

[Android.Runtime.Register("java/time/chrono/ChronoLocalDate", "", "Java.Time.Chrono.IChronoLocalDateInvoker", ApiSince=26)]
public interface IChronoLocalDate : IDisposable, Java.Interop.IJavaPeerable, Java.Lang.IComparable, Java.Time.Temporal.ITemporal, Java.Time.Temporal.ITemporalAdjuster

[<Android.Runtime.Register("java/time/chrono/ChronoLocalDate", "", "Java.Time.Chrono.IChronoLocalDateInvoker", ApiSince=26)>]
type IChronoLocalDate = interface
    interface IComparable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface ITemporal
    interface ITemporalAccessor
    interface ITemporalAdjuster

衍生

Java.Time.LocalDate

屬性

RegisterAttribute

實作

IJavaObject IJavaPeerable IComparable ITemporal ITemporalAccessor ITemporalAdjuster IDisposable

備註

一個沒有時間或時區的日期，採用任意時間順序，專為進階全球化的應用場景設計。

<b>大多數應用程式應該將方法簽名、欄位和變數宣告為 ，但不應將此介面宣 LocalDate告。</b>

A ChronoLocalDate 是某日期的抽象表示，其中 Chronology chronology或稱曆法系統可代拔。 日期以 所 TemporalField表示的欄位定義，大多數常見實作定義於 ChronoField。 年表定義了曆法系統的運作方式及標準欄位的意義。

<h2>何時使用此介面</h2> API 的設計鼓勵使用 LocalDate 而非此介面，即使應用程式需要處理多個行事曆系統。

這個概念乍看之下可能令人驚訝，因為全球化應用程式的自然方式乍看之下，可能看起來是抽象行事曆系統。 然而，如下所述，抽象行事曆系統通常是錯誤的方法，會導致邏輯錯誤和難以發現的錯誤。 因此，選擇使用此介面 LocalDate應視為整個應用程式架構上的決策，而非 。

<h3>架構問題需考慮</h3> 這些是在整個應用程式中使用此介面前必須考慮的一些重點。

1） 使用此介面的應用程式，相較於僅 LocalDate使用，面臨錯誤的機率顯著較高。 這是因為開發時所使用的曆法系統尚未被了解。 錯誤的主要原因之一是開發者將日常對 ISO 日曆系統的知識假設套用到本應處理任意曆法系統的程式碼中。 以下章節將說明這些假設如何可能引發問題。降低錯誤風險的主要機制是強而有力的程式碼審查程序。 這也應視為程式碼存續期間的額外維護成本。

2） 此介面不強制實作的不可變性。 雖然實作說明指出所有實作必須是不可變的，但程式碼或型別系統中並無強制執行此規定。 任何宣告接受 的方法 ChronoLocalDate ，都可能被傳遞出寫得不佳或惡意的可變實作。

3） 使用此介面的應用程式必須考慮時代的影響。 LocalDate 透過確保 getYear() 回溯預示年份，保護使用者免受時代概念的影響。 這個決定確保開發者可以將實例視為 LocalDate 三個欄位——年份、月份和月份。 相較之下，使用此介面的使用者必須將日期視為四個欄位——時代、年中、月份和月。 這個額外紀元欄位常被遺忘，但它對任意曆法系統中的日期至關重要。 例如，在日本曆法系統中，年號代表天皇的統治時期。 每當一個統治結束、另一個統治開始時，該時代的年份會重置為一。

4） 唯一公認的國際標準是 ISO-8601，該標準要求使用 ISO 日曆系統。 在整個應用程式中使用此介面，必然會導致必須跨越網路或元件邊界傳遞日期，這需要特定的應用程式協定或格式。

5） 長期持久化，例如資料庫，幾乎總是只接受 ISO-8601 日曆系統（或相關 Julian-Gregorian）中的日期。 在其他曆法系統中傳遞日期，增加了與持久性互動的複雜度。

6） 大多數情況下，整個申請過程中傳遞 a ChronoLocalDate 是不必要的，如下文最後一節所述。

<h3>錯誤假設導致多日曆系統程式碼<錯誤/h3> 如前所述，嘗試在任意曆法系統中使用和操作日期時，有許多問題需要考慮。 這些是關鍵議題。

查詢月份日期並假設該值永遠不會超過 31 的程式碼是無效的。 有些曆法系統在某些月份有超過31天的天數。

如果某個日期多了12個月，卻假設已經多了一年，這種代碼是無效的。 有些曆法系統的月份數不同，例如科普特語或衣索比亞語的13個月。

若程式碼在日期上加一個月，且假設月與年值會增加一或包裹到下一年，則無效。 有些曆法系統一年中有可變的月份數，例如希伯來曆。

如果程式碼加了一個月，再加一個月，並假設月日會接近原本值，這是無效的。 有些曆法系統中，最長月份和最短月份的長度差異很大。 例如，科普特或衣索比亞有12個月30天和1個月5天。

如果多了七天卻假設已經多了一週，則是無效的。 有些曆法系統的週數不是七天，例如法國大革命時期。

假設因為 年份 date1 大於 年份 date2 ，則 date1 在 之後 date2 ，則是 這在所有曆法系統中提及元年時都不成立，尤其在日本曆法中，因為每任天皇在位時，元年會重新開始。

將年度第一月和第一月第一日視為年度開始的程式碼是無效的。 並非所有曆法系統都是從月份值為一開始開始。

一般來說，當日曆系統在開發時未知時，操作日期甚至查詢日期都很容易出現錯誤。 因此，使用此介面的程式碼必須接受額外的程式碼審查。 這也是為什麼架構上選擇避免這種介面類型通常是正確的選擇。

<h3>使用 LocalDate< 代替 h3> 在整個申請過程中使用此介面的主要替代方案如下。 <ul><li>宣告所有以日期為 LocalDate單位的方法簽名。 <li>要麼將年表（日曆系統）儲存在使用者設定檔，要麼從使用者地點<查詢時間軸;li>在列印與解析LocalDate時將 ISO < 與使用者偏好的日曆系統 /ul 轉換 /ul> 這種方法將全球化日曆系統的問題視為在地化問題，並將其限制在使用者介面層。 這種做法與 Java 平台其他在地化問題相符。

如前所述，在曆法規則可代入的日期進行計算需要技巧，且不建議如此。 幸運的是，在任意曆法系統中對某個日期進行計算的需求極為罕見。 例如，圖書館書籍租賃計畫的商業規則極不可能允許借書期限為一個月，因為月份的意義取決於使用者偏好的行事曆系統。

在任意曆法系統中，對某日期進行計算的一個關鍵用例是產生一個按月計算的日曆，以便顯示與使用者互動。 這同樣是 UI 問題，僅在 UI 層的幾種方式中使用這個介面是合理的。

在系統的其他部分，若日期必須在非 ISO 的日曆系統中操作，使用情境通常會指定要使用的日曆系統。 例如，應用程式可能需要計算下一個伊斯蘭或希伯來節日，這可能需要操作日期。 這類使用情境可處理如下：ul<li 從傳遞的 ISO > 開始，將<>日期轉換成替代日曆系統，此使用情境中已知，而非LocalDate任意 li<執行計算 >li<轉回>< /ul>。撰寫低階框架或函式庫的開發者也應避免使用此介面。LocalDate<> 相反地，應使用兩種通用存取介面中的一種。 如果需要只讀存取，則使用 TemporalAccessor ;如果需要讀寫存取，則使用 Temporal 。

新增於1.8版本。

Java 文件 java.time.chrono.ChronoLocalDate。

本頁部分內容為基於 Open Source Project 所創建與分享的作品，並依授權條款所描述的使用進行修改。