最近我查看了 SimpleDateFormat 的文档并注意到他们处理解析字母的方式存在一些不一致(在我看来)。
例如，看看这些表示:
M: Month in year
D: Day in year
d: Day in month
“x inyear”的时间跨度比“xinmonth”更大，因此具有大写字母，因此这对我来说非常有意义。
但是还有
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 表示上午/下午的小时)
所以我的问题是:这种看似违反直觉的表示背后是否有原因？
我能想到的唯一原因是，其中一些模式字母是后来添加的，并且由于向下兼容性，它们无法更改已经存在的字母。但除此之外，这对我来说没有多大意义。
最佳答案
引用:
"The only reason i could think of is, that some of these pattern letters were added at a later time and they couldn't change the already existing ones, because of downwards compatibility."
你的怀疑是正确的。但你不能(只能)为此责怪 Sun 各自的 Oracle 设计者。他们刚刚取代了最初来自 Taligent(现已并入 IBM)的全部业务。 IBM 本身就是 Unicode 联盟背后的领先公司之一，该联盟定义了 CLDR-standard 。在该标准中，定义了所有这些图案符号(实际上以完全不一致的方式 - 只能通过历史发展来解释)。
更糟糕的是，CLDR 中的不一致现象并没有停止:最近，除了 SHORT、LONG 等之外，我们还有一个 NARROW 变体。这意味着如果您希望将一个月的可能表示形式作为单个字母，那么您需要指定模式符号 MMMMM(5 个字母，因为已经为数字缩写形式保留了一个字母 M)。
另一个注意事项:SimpleDateFormat 甚至不严格遵循 CLDR。例如，Oracle 在 Java 版本 7 中将模式符号“u”定义为 ISO-Day 周数(1 = 星期一，...，7 = 星期日)，尽管 CLDR 早先已经引入了相同的符号作为 proleptic ISO-年。 Java 8 再次偏离，发明了 CLDR 中未知的新符号，但试图更紧密地遵循 CLDR。
我们使用模式语言已经有了显着的差异(比较 Java-6、Java-7、Java-8、纯 CLDR 和 Joda-Time)。我担心这永远不会停止。
关于java - SimpleDateFormat:不一致的模式字母，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24525899/