我正在使用Joda-Time，我注意到DateTime在Google App Engine数据存储区中存储为java.util.Date，而LocalDateTime则存储为符合ISO 8601标准的字符串。

http://code.google.com/p/objectify-appengine/source/browse/src/com/googlecode/objectify/impl/translate/opt/joda/?r=2d48a85eae3a679c0dc0d01631de99f3b4775b29

我知道java.util.Date是数据存储区的本机类型。

与符合ISO 8601标准的字符串相比，将日期/时间存储为java.util.Date是否有任何特别的优点，或者它们都是相同的。 当我说优势时，我可能会考虑到...的差异

• 不平等查询
• 存储大小
• 读/写成本
• 等等

接受的答案没有错，但我想补充一些额外的细节，以提供更平衡的观点。

a)稳定的查询：只要你断言，ISO-8601就是稳定的

• 您只使用一种日期格式进行存储(ISO定义三种：日历日期，序数日期和星期日期)

• 并且您始终对时间部分使用一个精度(例如始终以毫秒为单位)

• 并且您总是在全局时间戳(使用符号Z为零偏移)时使用UTC。

确认这种稳定性可能与应用有关，而java.util.Date不需要同样的注意。

b)精度：ISO-8601可以表示超过毫秒的更高精度，而java.util.Date和Joda-Time在这里受到限制。如果您以后可能会想到其他新的时间库(如Java 8中的JSR-310或我自己的库提供纳秒精度)，则尤其如此。然后，对于所有JDBC类型java.util.Date和数据库列，您将遇到精度问题，只要它们不是CHAR或VARCHAR。

一个引人注目的例子是JDBC-type java.sql.Time，其精度仅限于秒，而不是更好。这与提供纳秒的新Java8型java.time.LocalTime形成鲜明对比。更糟糕的是：此方面也与应用程序层中的Joda-Time和java.util.Date相关。

出于相当的学术目的：Leapseconds只能以ISO-8601格式存储，而不能与java.util.Date或类似存储。

c)存储大小：当然，java.util.Date具有更紧凑的表示，但是我不得不说现在磁盘空间很便宜，所以这不是一件令人担心的事情。

d)读写成本：此项目支持像java.util.Date这样的紧凑数据类型。但是你还要考虑即使在这种情况下，你必须迟早在任何其他层中以人类可读的格式表示它(大多数在日志记录或表示层中)。所以对于与其他专有应用程序的数据交换，这些应用程序期望java.util.Date这种原生类型是可以的，但是为了记录目的或XML数据交换，ISO-8601可能是更好的格式。

如果你真的非常关心性能成本，你甚至可以考虑一种数字类型(长64位)来避免因不必要的对象创建造成的垃圾负担(在极端情况下)。请记住：java.util.Date只是一个很长的包装器。

java.util.Date的优点：稳定查询(不等式和相等)，存储大小以及与具有本机日期表示的其他GAE语言的互操作性。