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

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

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

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

有点晚了，但是Java在JDK 8中有一个新的日期时间API。您可能希望升级JDK版本并采用该标准。没有更多凌乱的日期/日历，没有更多第三方罐子。

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

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

日期应该用作不可变的时间点;日历是可变的，如果您需要与其他类协作以得出最终日期，则可以传递和修改日历。把它们看作类似于String和StringBuilder，您就会理解我认为应该如何使用它们。

(是的，我知道Date实际上在技术上不是不可变的，但目的是它不应该是不可变的，如果没有调用已弃用的方法，那么它就是不可变的。)

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

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

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

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

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

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