Java日期与日历

本文翻译自：Java Date vs Calendar

Could someone please advise the current "best practice" around Date and Calendar types. 有人可以建议Date和Calendar类型的当前“最佳做法”。

When writing new code, is it best to always favour Calendar over Date , or are there circumstances where Date is the more appropriate datatype? 在编写新代码时，最好是始终使用Calendar over Date ，还是在哪些情况下Date是更合适的数据类型？

---

#1楼

参考：https://stackoom.com/question/5tIY/Java日期与日历

---

#2楼

Date is a simpler class and is mainly there for backward compatibility reasons. Date是一个更简单的类，主要是出于向后兼容的原因。 If you need to set particular dates or do date arithmetic, use a Calendar. 如果您需要设置特定日期或进行日期算术，请使用日历。 Calendars also handle localization. 日历还处理本地化。 The previous date manipulation functions of Date have since been deprecated. 之前的Date日期操作函数已被弃用。

Personally I tend to use either time in milliseconds as a long (or Long, as appropriate) or Calendar when there is a choice. 就个人而言，当有选择时，我倾向于使用毫秒作为长（或适当的长）或日历。

Both Date and Calendar are mutable, which tends to present issues when using either in an API. 日期和日历都是可变的，在API中使用时往往会出现问题。

---

#3楼

Date is best for storing a date object. 日期最适合存储日期对象。 It is the persisted one, the Serialized one ... 它是持久的，序列化的......

Calendar is best for manipulating Dates. 日历最适合操纵日期。

Note: we also sometimes favor java.lang.Long over Date, because Date is mutable and therefore not thread-safe. 注意：我们有时也喜欢java.lang.Long而不是Date，因为Date是可变的，因此不是线程安全的。 On a Date object, use setTime() and getTime() to switch between the two. 在Date对象上，使用setTime（）和getTime（）在两者之间切换。 For example, a constant Date in the application (examples: the zero 1970/01/01, or an applicative END_OF_TIME that you set to 2099/12/31 ; those are very useful to replace null values as start time and end time, especially when you persist them in the database, as SQL is so peculiar with nulls). 例如，应用程序中的常量日期（示例：零1970/01/01，或者您设置为2099/12/31的应用END_OF_TIME;那些将空值替换为开始时间和结束时间非常有用，尤其是当你将它们保存在数据库中时，因为SQL对于null来说是如此奇特）。

---

#4楼

The best way for new code (if your policy allows third-party code) is to use the Joda Time library . 新代码的最佳方式（如果您的策略允许第三方代码）是使用Joda Time库 。

Both, Date and Calendar , have so many design problems that neither are good solutions for new code. 日期和日历都有很多设计问题，既不是新代码的好解决方案。

---

#5楼

• Date and Calendar are really the same fundamental concept (both represent an instant in time and are wrappers around an underlying long value). Date和Calendar实际上是相同的基本概念（两者都代表一个瞬间，并且是基础long值的包装）。

• One could argue that Calendar is actually even more broken than Date is, as it seems to offer concrete facts about things like day of the week and time of day, whereas if you change its timeZone property, the concrete turns into blancmange! 有人可能会说， Calendar实际上比Date更加破碎 ，因为它似乎提供了关于诸如星期几和时间等事情的具体事实，而如果你改变它的timeZone属性，那么具体变成了blancmange！ Neither objects are really useful as a store of year-month-day or time-of-day for this reason. 由于这个原因，这两个对象都不能用作年月日或时间的存储。

• Use Calendar only as a calculator which, when given Date and TimeZone objects, will do calculations for you. 仅将Calendar用作计算器，当给定Date和TimeZone对象时，它将为您进行计算。 Avoid its use for property typing in an application. 避免将其用于应用程序中的属性类型。

• Use SimpleDateFormat together with TimeZone and Date to generate display Strings. 将SimpleDateFormat与TimeZone和Date一起使用以生成显示字符串。

• If you're feeling adventurous use Joda-Time, although it is unnecessarily complicated IMHO and is soon to be superceded by the JSR-310 date API in any event. 如果你喜欢冒险使用Joda-Time，虽然它是不必要的复杂恕我直言，并且很快就会被JSR-310 date API取代。

• I have answered before that it is not difficult to roll your own YearMonthDay class, which uses Calendar under the hood for date calculations. 我之前已经回答过，推出自己的YearMonthDay类并不困难，因为它使用Calendar来进行日期计算。 I was downvoted for the suggestion but I still believe it is a valid one because Joda-Time (and JSR-310 ) are really so over-complicated for most use-cases. 我对这个建议进行了投票，但我仍然相信这是一个有效的建议，因为Joda-Time （和JSR-310 ）对于大多数用例来说真的太复杂了。

---

#6楼

I always advocate Joda-time . 我总是提倡乔达时间 。 Here's why. 这就是原因。

1. the API is consistent and intuitive. API一致且直观。 Unlike the java.util.Date/Calendar APIs 与java.util.Date/Calendar API不同
2. it doesn't suffer from threading issues, unlike java.text.SimpleDateFormat etc. (I've seen numerous client issues relating to not realising that the standard date/time formatting is not thread-safe) 它没有遇到线程问题，不像java.text.SimpleDateFormat等。（我看到很多客户端问题与未意识到标准日期/时间格式不是线程安全的）
3. it's the basis of the new Java date/time APIs ( JSR310 , scheduled for Java 8. So you'll be using APIs that will become core Java APIs. 它是新的Java日期/时间API（ JSR310 ，计划用于Java 8）的基础。因此，您将使用将成为核心Java API的API。

EDIT: The Java date/time classes introduced with Java 8 are now the preferred solution, if you can migrate to Java 8 编辑：如果您可以迁移到Java 8，Java 8引入的Java日期/时间类现在是首选解决方案