SimpleDateFormat：不一致的模式字母

Question

最近我查看了SimpleDateFormat的文檔，發現它們在處理字母解析方面存在一些不一致（在我看來）。

例如，看一下這些表示：

M: Month in year 
D: Day in year 
d: Day in month 

「X在今年」比「在一個月X」一個更大的時間跨度，並因此有大寫字母所以這使得我感覺良好。

但後來有

w: Week in year 
W: Week in month 

這裏，信件被交換，這在我看來是完全反直覺的。看起來這兩個應該是相反的方式，以符合上面提到的「模式」。

另一個例子是不同小時的表示：

H: Hour in day (0-23) 
k: Hour in day (1-24) 
K: Hour in am/pm (0-11) 
h: Hour in am/pm (1-12) 

我有點明白了。大寫字母的小時以0開頭，小寫字母的小寫字母以小寫字母開頭1. 在這裏，兩個小寫字母應該交換，因爲不應該是同一個字母屬於同一類別？ （H/h在一天小時，K/k在AM/PM小時）

所以我的問題是這樣的：會有這種看似違背直覺表示後面的原因是什麼？

我能想到的唯一原因是，這些模式字母中的一些是在稍後添加的，並且由於向下兼容性原因他們無法更改已經存在的字母。但除此之外，它對我來說沒有多大意義。

Answer 1

引文：

「的唯一原因，我能想到的是，其中一些圖案 字母都在稍後時間加入，他們不能改變 已經存在的，因爲向下的兼容性。」

您的懷疑是正確的。但是你不能（僅）責備Sun相應的Oracle設計師。他們剛剛完成了Taligent（現在合併到IBM）中的所有東西。 IBM本身是定義了CLDR-standard的Unicode聯盟背後的領先公司之一。在這個標準中，所有這些模式符號都被定義了（的確是以完全不一致的方式 - 只能通過歷史發展來解釋）。

更糟糕的是，CLDR的不一致性並沒有停止：最近除了SHORT，LONG等之外，我們還得到了一個N​​ARROW變體。這意味着如果你想將一個月的可能性表示爲單個字母，那麼你需要指定模式符號MMMMM（5個字母，因爲一個字母M已經爲數字簡寫形式保留）。

另一個通知：SimpleDateFormat甚至不嚴格遵循CLDR。例如，Oracle已經在Java版本7中將模式符號「u」定義爲ISO-Day週數（1 =星期一，...，7 =星期日），儘管CLDR已經在早期引入了與預測ISO-年。而Java 8再次出現偏差，發現了CLDR中未知的新符號，但其他人則試圖更緊密地遵循CLDR。我們已經在模式語言（比較Java-6，Java-7，Java-8，純CLDR和Joda-Time）方面有了顯着的不同。我擔心這永遠不會停止。