Question

前提

这个问题可能被合理地视为过于宽泛或以意见为导向，但无论如何我觉得我还有风险。

问题

Java的Formatter VS SimpleDateFormat API中说明的日期/时间转换格式之间存在许多难以理解的不一致。

例如：

M表示Formatter中的分钟，但SimpleDateFormat 中的月份，反之亦然
S和L分别代表Formatter中的秒和毫秒，但s和S分别代表SimpleDateFormat <中的秒和毫秒/ LI>
A和a分别代表Formatter中某一天的长/短名称，但SimpleDateFormat中的相同输出由<= 2表示vs > 2连续出现E，而a代表AM / PM标记，代之以SimpleDateFormat
等

问题（S）

是否存在一些合理化证明这些不一致的理由，例如：也许这两个班级使用不同的标准？
我只能从Formatter的API推断：

这些类型与GNU date和POSIX strftime(3c)定义的类型相似但不完全相同。
SimpleDateFormat似乎并不打算提及其惯例的基本原理
这两个约定是否在设计上任意和不一致，或者是否存在我不知道的隐含标准，这证明了这些不一致的原因？

Answer 1

<强>的SimpleDateFormat

正如@Tunaki所述，SimpleDateFormat使用Date Field Symbol Table定义的模式字符（由CLDR标准化，或 Unicode公共区域设置数据存储库）。

该项目被Google，IBM，Microsoft，Apple等许多公司广泛使用，以实现区域数据的广泛标准存储库，以及软件的国际化和本地化。这就是为什么某些日期/时间模式与来自不同编程语言的其他模式非常相似的原因。

此外，除了统治way we use date, time and time zone之外，指定排序规则，键盘映射，数字，货币等标准非常重要。此外，它还定义了当我们尝试解析时会发生什么？日语日期，例如

为了理解这一点，我们必须说明what means a "parsing" process：

时间点（UDate）与一组日历字段之间的映射，而后者依赖于：

特定日历系统的规则（例如格里高利，佛教，中国农历）

时区



一组日历字段和格式化文本表示之间的映射，这取决于选择用于显示的字段，   他们的展示风格，以及特定区域的惯例。

因此，有必要知道"MMMMdjmm"的骨架可能会导致不同语言环境的以下格式模式：

Locale | format pattern
------ | ---------------------
en_US  | "MMMM d 'at' h:mm a"
es_ES  | "d 'de' MMMM, H:mm"  
ja_JP  | "M月d日 H:mm"

<强>格式化

Formatter＆＃34;采用的原因＆＃34;不同的格式化模式是因为这个类应该是printf样式格式字符串的解释器，它非常接近GNU date和POSIX strftime(3c)现实（作为official docs states）。

来自GNU docs：

date命令的输出并不总是可以接受为日期   字符串，不仅是因为语言问题，还因为   对于像IST＆＃39;这样的时区项目没有标准含义。

使用date生成要在以后解析的日期字符串时，   指定一种独立于语言的日期格式   不使用＆＃39; UTC＆＃39;以外的时区项目和＆＃39; Z＆＃39;。

让我们看一下GNU的简单日期/时间示例：

TZ=UTC0 date +'%Y-%m-%d %H:%M:%SZ'
// Output: 2004-03-01 00:21:42Z

注意printf风格以及使用Formatter类的相同转换字符。

然而，文档还说他们只是相似，不相同。这是因为Java为特定字段选择了一些灵活性，例如'z'案例：

RFC 822样式数字时区偏离GMT，例如-0800。这个值将根据夏令时的需要进行调整。

Formatter VS DateFormat不一致

1 个答案: