我一直提倡joda时间。这是为什么。

API是一致的和直观的。不像java.util。日期/日历api 它没有线程问题，不像java.text.SimpleDateFormat等(我见过许多客户端问题，没有意识到标准日期/时间格式不是线程安全的) 它是新的Java日期/时间api (JSR310，计划在Java 8中发布)的基础。因此，您将使用的api将成为核心Java api。

编辑:如果可以迁移到Java 8, Java 8引入的Java日期/时间类现在是首选的解决方案

Date最适合存储日期对象。它是持久化的，序列化的…

日历是操作日期的最佳工具。

注意:我们有时也更喜欢java.lang.Long而不是Date，因为Date是可变的，因此不是线程安全的。在Date对象上，使用setTime()和getTime()在两者之间切换。例如，应用程序中的一个常量Date(例如:0 1970/01/01，或应用程序的END_OF_TIME，您设置为2099/12/31;这些对于替换null值作为开始时间和结束时间非常有用，特别是当您在数据库中持久化它们时，因为SQL对null非常特殊)。

Date是一个更简单的类，主要是为了向后兼容。如果需要设置特定的日期或进行日期计算，请使用Calendar。日历也处理本地化。date之前的日期操作函数已弃用。

就我个人而言，如果有选择的话，我倾向于使用以毫秒为单位的时间作为long(或long，视情况而定)或Calendar。

Date和Calendar都是可变的，这在API中使用时往往会出现问题。

顺便说一句，“日期”通常被标记为“过时/弃用”(我不知道确切的原因)-关于它的一些东西写在那里 Java:为什么日期构造函数弃用，我用什么代替?

看起来这是一个构造函数的问题-方法通过新日期(int年，int月，int日)，推荐的方法是通过日历和设置参数分开。(Calendar cal = Calendar. getinstance (); ）

Date and Calendar are really the same fundamental concept (both represent an instant in time and are wrappers around an underlying long value). 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! 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. Avoid its use for property typing in an application. Use SimpleDateFormat together with TimeZone and Date to generate display Strings. 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. I have answered before that it is not difficult to roll your own YearMonthDay class, which uses Calendar under the hood for date calculations. 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.

日期应该重新开发。它不应该是一个长整数，而应该包含年、月、日、小时、分钟、秒作为单独的字段。甚至还可以存储这个日期所关联的日历和时区。

在我们平常的谈话中，如果你安排的约会时间是纽约时间2013年11月1日下午1点，这就是“约会时间”。它不是日历。所以我们在Java中也应该能够像这样交谈。

当Date存储为一个长整数(自1970年1月1日以来的毫秒数)时，计算其当前日期取决于日历。不同的日历会给出不同的日期。这是从给出绝对时间(如大爆炸后1万亿秒)的角度出发的。但通常我们也需要一种方便的对话方式，比如一个对象可以封装年、月等。

我想知道Java中是否有新的进展来协调这两个目标。也许我的java知识太老了。