date - Java中`uuuu`中`yyyy`与`DateTimeFormatter`的格式格式代码？

DateTimeFormatter 类文档说明了其年份的格式代码:

没有其他提及“时代”。
那么，这两个代码u与y和year与year-of-era有什么区别？
在Java中使用日期时，何时应使用这种模式uuuu-MM-dd和yyyy-MM-dd？
似乎那些由知识渊博的人编写的示例代码使用uuuu，但是为什么呢？
其他格式类(例如旧版 SimpleDateFormat )仅包含yyyy，因此我很困惑为什么java.time将此uuuu带入了“时代”。

最佳答案

在java.time -package的范围内，我们可以说:

使用“u”而不是“y” 更加安全，因为 DateTimeFormatter 否则将坚持使用与“y”(=年)组合的时代。因此，使用“u”将避免在严格的格式/解析中出现一些可能的意外异常。另请参见SO-post。与“y”相比，用“u”符号改进的另一个小问题是打印/解析负格里高利历年(很久以前)。

否则，我们可以清楚地声明使用“u”而不是“y”的打破了Java编程中的长期习惯。从直觉上也不清楚“u”表示任何年份，因为a)英文单词“year”的首字母与该符号不一致，并且b)SimpleDateFormat自Java以来​​就将“u”用于其他目的-7(ISO-day-number-of-week)。困惑得到了保证-永远吗？

我们还应该看到，如果考虑历史日期，则在ISO上下文中使用纪元(符号“G”)的通常很危险。如果将“G”与“u”一起使用，则两个字段互不相关。并且，如果将“G”与“y”一起使用，则格式化程序可以满足要求，但当历史日期要求使用不同的日历和日期处理时，仍使用多用公历。

背景资料:
在开发和集成JSR 310(java.time -packages)时，设计人员决定使用Common Locale Data Repository (CLDR) / LDML-spec作为DateTimeFormatter中的模式符号的基础。 CLDR中已经将符号“u”定义为公历公历年份，因此此含义已用于新的即将发布的JSR-310(但由于向后兼容的原因而未用于SimpleDateFormat)。
但是，遵循CLDR的决定并不一致，因为JSR-310还引入了CLDR中不存在，仍然不存在的新模式符号，另请参见此旧CLDR-ticket。建议的符号“I”被CLDR更改为“VV”，并最终被JSR-310取代，包括new symbols "x" and "X"。但是CLDR中仍然不存在“n”和“N”，并且由于该旧凭单已关闭，因此尚不清楚CLDR是否会支持JSR-310。此外，票证没有提及符号“p”(JSR-310中的填充指令，但未在CLDR中定义)。 因此，在跨不同库和语言的模式定义之间，我们仍未达成完美的协议(protocol)。
关于“y”:我们也不应忽略以下事实:CLDR将这一年份与至少某种混合的朱利安/格里高利安年份联系在一起，而不是像JSR-310那样与多义的格里高利年份联系在一起(排除负数年)。因此，CLDR和JSR-310之间也没有完美的协议(protocol)。