最近，我查看了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）所以我的问题是：这种看似反直觉的表象背后有原因吗？
我能想到的唯一原因是，某些模式字母是在以后添加的，并且由于向下兼容性，它们无法更改已经存在的模式字母。但是除此之外，这对我来说没有多大意义。
最佳答案
引文：
“我能想到的唯一原因是，其中一些模式
信件是在以后添加的，因此无法更改
由于向下兼容，因此已经存在。”
您的怀疑是正确的。但是，您不能（只能）为此责怪Sun各自的Oracle设计人员。他们刚刚超过了Taligent（现在已合并到IBM）的全部业务。 IBM本身是Unicode联盟背后的领先公司之一，该联盟定义了CLDR-standard。在该标准中，所有这些图案符号均已定义（实际上完全不一致，只能由历史发展来解释）。
更糟糕的是，CLDR中的不一致并没有停止：最近，除了SHORT，LONG等，我们还有NARROW变体。这意味着如果您希望将一个月的缩写表示为单个字母，则需要指定模式符号MMMMM（5个字母，因为一个数字M已经保留了一个字母M）。
另一个通知：SimpleDateFormat甚至没有严格遵循CLDR。例如，在Java版本7中，Oracle已将模式符号“ u”定义为ISO天的星期数（1 =星期一，...，7 =星期日），尽管CLDR早于多用ISO-已经引入了相同的符号。年。 Java 8再次出现偏差，发明了CLDR中未知的新符号，但尝试更紧密地遵循CLDR。
使用模式语言（比较Java-6，Java-7，Java-8，纯CLDR和Joda-Time）已经有了显着差异。我担心这将永远不会停止。