是否有任何特定原因在 API 中使用 Date 类（例如，在员工出生日期字段中）而不是 long 或 Long。
对此有一些讨论： java-date-vs-calendar，但我想特别知道是否有任何理由使用日期，当长（或长）看起来更简单时。
当然，我会使用 TimeZone 和 SimpleDateFormatter 在 GUI 中解析和显示日期，也许还会使用 Calendar 来执行操作，但我只关心这个问题中数据模型/API 中日期的存储和表示。
更新：我不选择 Date 的一个原因是它是可变的。因此，如果我在我的 API 中公开一个日期，调用者可以调用 setTime(long)，这似乎违反了基本封装。对我来说，这似乎超过了使用 Date 提供的额外清晰度的好处，因为我可以调用长属性 timeInMillisecondsSinceEpoch 并将相同的信息传达给调用者。
如果您在 API 中使用整数来表示日期，您将添加额外的、不必要的复杂层，这将需要额外的文档并使您的 API 更难使用。
通过使用整数，您必须让客户知道基准日期是什么，您正在测量什么（例如秒、毫秒、分钟等？）并强制客户进行转换。在您的 API 中保留一个 Date 对象会使 IMO 更简单、更友好。除非出于某种原因，存在非常严重的性能影响，否则我建议将 Date 保留在您的 API 中，即使您需要在内部进行更多编码。这就是使一个好的 API 成为一个好的 API 的原因之一......不要让你的客户跳过箍。
就个人而言，与 Java 中的日期和时间 API 一样糟糕，我倾向于使用Date. 它只是具有更多的语义价值。此外，您不必猜测它是秒还是毫秒。
日期不是一个数字，它是一个时间点。您可以用数字表示这一事实是应该隐藏的实现细节。
该类Date是 API 的一部分，如果它符合您的目的，它也是一个有效的选项。其中有许多已弃用的方法已被Calendar类替换，因此请确保避免使用这些方法。
答案将取决于您需要完成什么。如果只需要按日期排序，along就绰绰有余了。一个Date值会增加一些可读性，但不会增加更多功能。使用Date也不会有害，因此应考虑可读性因素。
如果该字段是私有的，您实际上可以将其存储为 long 并有一个 getter 和一个 setter 使用Date：
private long mDOB;
public Date getDOB () { return new Date(mDOB);}
public void setDOB (Date dob) { mDOB = dob.getTime(); }