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

问题描述

在Java 8中有这个新的酷酷的Date 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 因为新的Date API而变得过时了，类似于替换 Gavaava FluentIterable ？

• 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!

请参阅教程< a href =http://docs.oracle.com/javase/tutorial/datetime/iso/legacy.html =noreferrer>遗产日期时间码。

此外， 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团队的广泛使用，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类 em>远高于，这就是为什么他们被添加。它们更合乎逻辑，更易于使用。那么是的，学习如何使用它将是有益和愉快的。但不紧急在紧张的时候，用旧的方式编写代码。当你有足够的时间学习（教程），并执行额外的测试，开始使用新课。

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.

由于新的Date API类似于Java 8流API代替Guava FluentIterable，Joda Time API是否过时？

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时间是java.time的灵感。同样的人发明了两者。他们打算让java.time成为他们的2.0重发Joda-Time，如果他们知道他们现在知道的话，他们会做什么。他们说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每个都有其他缺点的功能。所以个人来说，我混合搭配最适合。我依靠Joda-Time同时使用java.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与日历/日期/ DateFormat的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！