Java中`DateTimeFormatter`格式化模式代码中的`uuuu`与`yyyy`? [英] `uuuu` versus `yyyy` in `DateTimeFormatter` formatting pattern codes in Java?

问题描述

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

The DateTimeFormatter class documentation says about its formatting codes for the year:

u 年 2004 年；04

u year year 2004; 04

2004 年；04

…

年份:字母数决定了最小字段宽度，低于该宽度时使用填充.如果字母数是两个，则使用减少的两位数形式.对于打印，这会输出最右边的两位数字.对于解析，这将使用基值 2000 进行解析，从而生成 2000 到 2099 范围内的年份.如果字母数少于四个(但不是两个)，则符号仅根据 SignStyle.NORMAL 输出负年份.否则，如果超过焊盘宽度，则根据 SignStyle.EXCEEDS_PAD 输出符号.

Year: The count of letters determines the minimum field width below which padding is used. If the count of letters is two, then a reduced two digit form is used. For printing, this outputs the rightmost two digits. For parsing, this will parse using the base value of 2000, resulting in a year within the range 2000 to 2099 inclusive. If the count of letters is less than four (but not two), then the sign is only output for negative years as per SignStyle.NORMAL. Otherwise, the sign is output if the pad width is exceeded, as per SignStyle.EXCEEDS_PAD.

没有其他提及时代".

那么这两个代码有什么区别，u 与 y，year 与 year-of-era?

So what is the difference between these two codes, u versus y, year versus year-of-era?

在 Java 中处理日期时，我什么时候应该使用这种模式 uuuu-MM-dd 和 yyyy-MM-dd 什么时候?

When should I use something like this pattern uuuu-MM-dd and when yyyy-MM-dd when working with dates in Java?

似乎那些知情者编写的示例代码使用 uuuu，但为什么呢?

Seems that example code written by those in the know use uuuu, but why?

其他格式化类，例如遗留的SimpleDateFormat 只有yyyy，所以我很困惑为什么java.time 为时代"带来这个uuuu.

Other formatting classes such as the legacy SimpleDateFormat have only yyyy, so I am confused why java.time brings this uuuu for "year of era".

推荐答案

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

Within the scope of java.time-package, we can say:

• 使用u"更安全而不是y"，因为DateTimeFormatter 否则会坚持将一个时代与y"结合起来.(= 时代).所以使用u"将避免在严格的格式/解析中出现一些可能的意外异常.另请参阅此SO-post.与y"相比，u"符号改进的另一个小问题是正在打印/解析负的公历年(在很久以前).

• It is safer to use "u" instead of "y" because DateTimeFormatter will otherwise insist on having an era in combination with "y" (= year-of-era). So using "u" would avoid some possible unexpected exceptions in strict formatting/parsing. See also this SO-post. Another minor thing which is improved by "u"-symbol compared with "y" is printing/parsing negative gregorian years (in far past).

否则我们可以清楚地声明使用u"而不是y"打破 Java 编程中长期存在的习惯.u"在直觉上也不是很清楚.表示任何种类的年份，因为 a) 英文单词year"的第一个字母；不同意这个符号并且 b) SimpleDateFormat 使用了u"自 Java-7 (ISO-day-周数).混乱是有保证的 - 永远?

Otherwise we can clearly state that using "u" instead of "y" breaks long-standing habits in Java-programming. It is also not intuitively clear that "u" denotes any kind of year because a) the first letter of the English word "year" is not in agreement with this symbol and b) SimpleDateFormat has used "u" for a different purpose since Java-7 (ISO-day-number-of-week). Confusion is guaranteed - for ever?

我们还应该看到如果我们考虑历史日期，在 ISO 上下文中使用纪元(符号G")通常是危险的.如果G"与u"一起使用那么这两个字段彼此无关.如果G"与y"一起使用那么格式化程序就满意了，但当历史日期要求使用不同的日历和日期处理时，它仍然使用公历.

We should also see that using eras (symbol "G") in context of ISO is in general dangerous if we consider historic dates. If "G" is used with "u" then both fields are unrelated to each other. And if "G" is used with "y" then the formatter is satisfied but still uses proleptic gregorian calendar when the historic date mandates different calendars and date-handling.

在开发和集成 JSR 310 (java.time-packages) 设计者决定使用 Common Locale Data Repository (CLDR)/LDML-spec 作为 DateTimeFormatter 中模式符号的基础.符号u"已在 CLDR 中定义为预兆公历年，因此该含义被用于新的即将推出的 JSR-310(但由于向后兼容的原因未用于 SimpleDateFormat).

When developing and integrating the JSR 310 (java.time-packages) the designers decided to use Common Locale Data Repository (CLDR)/LDML-spec as the base of pattern symbols in DateTimeFormatter. The symbol "u" was already defined in CLDR as proleptic gregorian year, so this meaning was adopted to new upcoming JSR-310 (but not to SimpleDateFormat because of backwards compatibility reasons).

然而，这个遵循 CLDR 的决定并不完全一致，因为 JSR-310 还引入了新的模式符号，这些符号在 CLDR 中不存在并且仍然不存在，另见这个旧的 CLDR-ticket.建议的符号I"已被 CLDR 更改为VV"并最终被 JSR-310 超越，包括 新符号x"和X".但是n"和N"CLDR 中仍然不存在，并且由于这张旧票已关闭，因此根本不清楚 CLDR 是否会在 JSR-310 的意义上支持它.此外，票没有提到符号p".(JSR-310 中的填充指令，但未在 CLDR 中定义).因此，我们在不同库和语言之间的模式定义之间仍然没有完全一致.

However, this decision to follow CLDR was not quite consistent because JSR-310 had also introduced new pattern symbols which didn't and still don't exist in CLDR, see also this old CLDR-ticket. The suggested symbol "I" was changed by CLDR to "VV" and finally overtaken by JSR-310, including new symbols "x" and "X". But "n" and "N" still don't exist in CLDR, and since this old ticket is closed, it is not clear at all if CLDR will ever support it in the sense of JSR-310. Furthermore, the ticket does not mention the symbol "p" (padding instruction in JSR-310, but not defined in CLDR). So we have still no perfect agreement between pattern definitions across different libraries and languages.

关于y":我们也不应该忽视这样一个事实，即 CLDR 将这一年与至少某种混合的儒略/格里高利年联系起来，而不是像 JSR-310 那样与预测的格里高利年联系在一起(撇开负年份的奇怪之处).所以这里也没有 CLDR 和 JSR-310 之间完美的一致.

And about "y": We should also not overlook the fact that CLDR associates this year-of-era with at least some kind of mixed Julian/Gregorian year and not with the proleptic gregorian year as JSR-310 does (leaving the oddity of negative years aside). So no perfect agreement between CLDR and JSR-310 here, too.

这篇关于Java中`DateTimeFormatter`格式化模式代码中的`uuuu`与`yyyy`?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！