oracle日期格式化，java日期格式化代码的写法_Java中的`DateTimeFormatter`格式化代码中的`uuuu`与`yyyy`？...

在java.time-package的范围内,我们可以说：

oracle日期格式化，>使用“u”代替“y”更安全,因为DateTimeFormatter将坚持将时代与“y”(=年代)相结合.因此,使用“u”可以避免在严格的格式化/解析中出现一些可能的意外异常.另请参阅此SO-post.“u”-symbol与“y”相比改进的另一个小问题是打印/解析负的格里高利年(远在过去).

>否则我们可以清楚地说明使用“u”而不是“y”打破了Java编程中的长期习惯.直觉上也不清楚“u”表示任何一种年份,因为a)英语单词“year”的第一个字母与此符号不一致b)SimpleDateFormat使用“u”表示不同的目的,因为Java -7(ISO-day-number-of-week).混乱得到保证 – 永远？

>我们还应该看到,如果我们考虑历史日期,在ISO的背景下使用时代(符号“G”)通常是危险的.如果“G”与“u”一起使用,则两个字段彼此无关.如果“G”与“y”一起使用,则格式化程序会满意,但在历史日期强制执行不同的日历和日期处理时仍使用预知的格里高利历.

背景资料：

在开发和集成JSR-310(java.time-packages)时,设计人员决定使用CLDR / LDML-spec作为DateTimeFormatter中模式符号的基础.符号“u”已经在CLDR中定义为一个普通的格里高利年,所以这个意思被新的即将到来的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中定义).因此,我们在不同的库和语言之间的模式定义之间仍然没有完全一致.

而关于“y”：我们也不应忽视CLDR将这一年与至少某种混合的朱利安/格里高利年联系在一起的事实,而不是像JSR-310那样将这个年代与格雷戈里年联系起来(留下奇怪之处)消极年份除外).因此,CLDR和JSR-310之间也没有完美的协议.