为什么Java 8 java.time类缺少getMillis（）方法？

Java 8在java.time包中提供了一个用于日期和时间的全新库，这对于以前必须使用JodaTime或使其成为自己的日期处理助手方法而感到烦恼的人来说，是一件非常受欢迎的事情。该程序包中的许多类都表示时间戳，并具有一些辅助方法，例如getHour()从时间戳获取小时，从时间戳getMinute()获取分钟，从时间戳getNano()获取nano等。

我注意到他们没有一种方法getMillis()来获取时间戳的毫秒数。相反，必须调用method get(ChronoField.MILLI_OF_SECOND)。在我看来，这似乎是图书馆中的矛盾之处。有谁知道为什么缺少这种方法，或者由于Java 8仍在开发中，是否有可能稍后再添加呢？

https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html

此处定义的类代表主要的日期时间概念，包括瞬间，持续时间，日期，时间，时区和时间段。它们基于ISO日历系统，这是遵循通用格里高利规则的事实世界日历。所有的类都是不可变的并且是线程安全的。

每个日期时间实例均由API方便提供的字段组成。对于较低级别的字段访问，请参考java.time.temporal软件包。每个类都支持打印和解析各种日期和时间。请参阅java.time.format软件包以获取自定义选项...

此类示例：https :
//docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html

ISO-8601日历系统中没有时区的日期时间，例如2007-12-03T10：15：30。

LocalDateTime是一个不变的日期时间对象，代表一个日期时间，通常被视为年-月-日-时-分-秒。也可以访问其他日期和时间字段，例如，一年中的某天，一周中的某天和一周中的某周。时间以纳秒精度表示。例如，值“ 2nd October 2007 at 13：45.30.123456789”可以存储在LocalDateTime...中

JSR-310基于纳秒，而不是毫秒。因此，最小的明智方法集基于小时，分钟，秒和纳秒。拥有十亿分之一秒的决定是该项目的最初决定之一，我坚信这一决定是正确的。

添加毫微秒的方法将与纳秒的方法重叠是一种非显而易见的方法。用户将不得不考虑例如纳米场是纳秒级还是毫微米级。添加一个令人迷惑的附加方法是不可取的，因此省略了该方法。如所指出的，替代方案get(MILLI_OF_SECOND)是可用的。

FWIW，我反对getMillis()将来添加该方法。

在加入openJDK之前，Threeten在github上，在此之前在sourceforge上。那时，jsr-310的规范负责人Stephen Colebourne进行了一项调查，您仍然可以在sourceforge网站上找到该调查。

The fourth question on the survey covered the method names for LocalTime:
1) getHourOfDay(), getMinuteOfHour(), getSecondOfMinute(), getNanoOfSecond()
2) getHour(), getMinute(), getSecond(), getNanoOfSecond()
3) getHour(), getMinute(), getSecond(), getNano()
4) another idea

只有6.23％的人选择了答案4，其中大约15％的人要求getMillis()，即不到总选票的1％。

这可能就是为什么一开始就没有的原因，getMillis而我在openjdk邮件列表中找不到任何相关内容，因此此事之后显然没有讨论。

代表明确的UTC时间的类（即Instant，OffsetDateTime，ZonedDateTime）具有两个帮助程序方法，用于访问Java纪元的绝对偏移量，即在java.util.Date中称为“毫秒时间”的方法，您可以使用达到毫秒

long getEpochSecond()
int getNano()

1000L*getEpochSecond() + getNano() / 1000000L;

在jsr 310邮件列表long getEpochMillis()中讨论了为什么选择了它而不是选择它的一些原因，为方便起见，我提取了其中的一些原因：

假设毫秒精度不够是合理的。但是，任何大于纳秒精度的东西似乎都是过分的

...

为了实现这一点，我的首选选项是64位长秒（有符号）+ 32位int纳秒（无符号）。

...

我更喜欢将拆分设置为第二级，因为这是科学中SI的官方时间单位，也是最普遍认可的标准。

由于无法处理level秒，因此在天数级拆分对于即时而言是有问题的。以毫秒为单位进行拆分，同时与Java的其余部分更好地集成，这看起来确实很奇怪。另外，它会在支持的范围内丢失。

按照提议，在第二秒分裂会产生超过2900亿年的纳秒范围。虽然没有人应该在时间范围内使用该精度，但我建议它比阻止它更容易支持。在天数级上拆分对于瞬间来说是有问题的，因为它无法处理leap秒

我感觉到另一个原因是有意使从java.util.Date转换为JSR310类变得困难，希望开发人员将尝试理解各种选项之间的差异，而不仅仅是盲目地（错误地）使用新类。

关于LocalDateTime类为什么没有这些方法的原因-它们可能在那里不存在，因为LocalDateTime在确定您所在的区域或UTC偏移量之前，它不依赖于UTC时间轴，此时您将拥有一个OffsetDateTime或ZonedDateTime（两者都有所需的方法）。

另外，您可以定义自己的LOCAL_EPOCH常量to 1970-01-01T00:00:00，然后执行a MILLIS.between(LOCAL_EPOCH, localTime)以获取某种持续时间（以毫秒为单位）。但是，该值将不会与System.currentTimeMilliseconds()或返回的任何值兼容java.util.Date.getTime()，除非您将本地时间定义为UTC时间。但是在这种情况下，您最好直接使用Instant或将OffsetDateTime与ZoneOffset.UTC一起使用。