Java 8 日期 API 与日历/日期/日期格式 [英] Java 8 Date API vs Calendar / Date / DateFormat

问题描述

Java 8 中有这个新的很酷的日期 API，java.time 包.据我所知，它比旧类设计得更好、更明确、更线程安全.不过，我不确定如何使用它:

There is this new-n-cool Date API in Java 8, the java.time package. I understand that it is better designed, less ambiguous and more thread-safe than the old classes. Still, I am not sure how to go about using it:

• 我应该只使用它而不是旧类吗?
• 我应该在我发现旧类的任何地方替换它们的现有用法，因为新的东西要好得多吗?
• 我是否应该避免使用 java.util.Calendar、java.util.Date、java.sql.Date 和 java.text.DateFormat一起支持新 API 还是有用例旧类仍然更可取?
• Joda Time API 是否已过时，这要归功于类似于替换 Guava FluentIterable 来自 Java 8 流 API?

• Should I use it exclusively instead of the old classes?
• Should I replace existing usages of old classes whereever I spot them because the new stuff is so much better?
• Should I refrain from using java.util.Calendar, java.util.Date, java.sql.Date and java.text.DateFormat in favor of the new API all together OR are there use cases where the old classes are still preferable?
• Has the Joda Time API become obsolete thanks to the new Date API similarly to the substitution of Guava FluentIterable by Java 8 stream API?

我知道这些问题很多，但感觉彼此之间有些关联.如果有人能回答所有问题，那就太棒了，但也感谢部分好的回答.

I know these are a lot of questions, but they feel somewhat related to each other. If somebody can answer the whole bunch, that would be awesome, but good partial answers are also appreciated.

推荐答案

我应该只使用它而不是旧类吗?

Should I use it exclusively instead of the old classes?

不，不需要排除旧类.旧的 java.util.Date/.Calendar 工作相同，没有改变.已未被弃用.

No, no need to exclude old classes. The old java.util.Date/.Calendar work the same, unchanged. The have not been deprecated.

您可以混合搭配所有三个框架(旧类、Joda-Time 和 java.time).小心一些相同或相似的类名——注意你的 import 语句！

You can mix and match all three frameworks (old classes, Joda-Time, and java.time). Just be careful of some identical or similar class names -- watch your import statements!

请参阅教程，传统日期时间代码.

此外，ThreeTen-Extra 项目通过附加功能扩展了 java.time.ThreeTen"指的是定义 java.time 的 JSR 310.

Also, the ThreeTen-Extra project extends java.time with additional features. The "ThreeTen" refers to JSR 310 that defines java.time.

我应该在我发现旧类的任何地方替换它们的现有用法吗，因为新的东西好多了?

Should I replace existing usages of old classes whereever I spot them because the new stuff is so much better?

如果旧代码按预期工作，那么现在无需更改.

If the old code is working as intended, then no need to change now.

如果您担心旧代码可能无法正确处理时区，或者一直想要进行更多本地化，您可能想使用 java.time 重新编写它们.即便如此，请记住，您可以轻松地在 j.u.Date 和 Instant 之间进行转换.因此，您可以将业务逻辑与 j.u.Date/.Calendar 保持原样，并仅更改用户表示代码以使用 java.time.

If you were concerned about that old code possibly not handling time zones properly or have been wanting to do more localization, the you might want to rework them using java.time. Even then, remember that you can easily convert between j.u.Date and Instant. So you could leave your business logic as-is with j.u.Date/.Calendar and change only the user-presentation code to use java.time.

我是否应该避免使用 java.util.Calendar、java.util.Date、java.sql.Date 和 java.text.DateFormat 来支持新的 API，或者是否存在旧类仍然存在的用例更可取?

Should I refrain from using java.util.Calendar, java.util.Date, java.sql.Date and java.text.DateFormat in favor of the new API all together OR are there use cases where the old classes are still preferable?

您将需要旧类与旧代码和需要旧类型的库进行互操作.同样，旧类不会被弃用，也不会消失.鉴于它们的广泛使用以及 Java 团队的首要任务是保持向后兼容性，它们可能永远不会消失.

You will need the old classes for interoperation with old code and libraries that expect the old types. Again, the old classes are not deprecated and are not going away. They will probably never go away given their extensive usage and the Java team’s top priority being preservation of backward-compatibility.

新的 java.time 类 远胜于其他类，这就是添加它们的原因.而且它们更合乎逻辑，更易于使用.所以是的，学习如何使用它们将是有益和愉快的.但不紧急.在紧要关头，按照您习惯的旧方式编写代码.当您有时间学习(教程)并执行额外的操作时测试，开始使用新类.

The new java.time classes are far superior, that's why they were added. And they are more logical and easier to use. So yes, it would be beneficial and pleasant to learn how to use them. But not urgent. In a crunch, write code the old way you are used to. When you can afford the time to learn (Tutorial) and to perform extra testing, start to use the new classes.

新手程序员当然应该将学习重点放在 java.time 上.

A newbie programmer should certainly focus their learning on java.time.

Joda Time API 是否因新的 Date API 过时而类似于 Java 8 流 API 替代 Guava FluentIterable?

Has the Joda Time API become obsolete thanks to the new Date API similarly to the substitution of Guava FluentIterable by Java 8 stream API?

Joda-Time 是 java.time 的灵感来源.同一个人发明了两者.他们打算让 java.time 成为他们对 Joda-Time 的2.0"重新发明，如果他们知道他们现在所知道的，他们当时会做什么.他们说 Joda-Time 用户应该过渡到 java.time.

Joda-Time was the inspiration for java.time. The same folks invented both. They intend for java.time to be their "2.0" re-invention of Joda-Time, what they would have done then if they knew what they know now. They have said Joda-Time users should transition over to java.time.

也就是说，Joda-Time 不会消失.它仍在开发中，仍然更新了错误修复和新的 tz 时区数据.对于没有其他像样的日期时间库(我知道)的大型 Android 社​​区来说，这非常很重要.因此，您可以继续依赖 Joda-Time，无需迫切需要删除旧代码，但也不会期望有新功能或增强功能.

That said, Joda-Time is not going away. It is still worked on, still updated with bug fixes and fresh tz time zone data. And it is very important to the large Android community who have no other decent date-time library (that I know of). So you can continue to rely on Joda-Time, no urgent need to rip out old code, but expect no new features or enhancements.

Joda-Time 已经久经考验，而 java.time 有一些小错误和问题需要解决.Joda-Time 和 java.time 各有各的特点.所以就个人而言，我混合搭配以最适合.我在涉足 java.time 时依赖 Joda-Time.

Joda-Time is well-worn and proven while java.time has had a few minor bugs and kinks to work out. Joda-Time and java.time each have features the other lacks. So personally, I mix-and-match to best fit. I rely on Joda-Time while dabbling with java.time.

计划最终过渡到 java.time，但不要着急，不要恐慌.

Plan an eventual transition to java.time but no rush, no panic.

这篇关于Java 8 日期 API 与日历/日期/日期格式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！