我正在使用Joda-Time，我注意到DateTime在Google App Engine Datastore for Java中存储为java.util.Date，而LocalDateTime则存储为符合ISO 8601标准的字符串。
我知道java.util.Date是数据存储区的本机类型。
与符合ISO 8601的字符串相比，将日期/时间存储为java.util.Date是否有任何特别的优点，或者它们都是相同的。当我说优势时，我可能会考虑与......的差异。
答案 0 :(得分：3)
接受的答案并没有错，但我想补充一些额外的细节，以提供更平衡的观点。
a）稳定的查询：只要您声明
，ISO-8601就是稳定的您只使用一种日期格式进行存储（ISO定义三种：日历日期，序数日期和星期日期）
并且您始终对时间部分使用一个精度（例如始终以毫秒为单位）
并且您始终对全局时间戳（使用符号Z为零偏移）使用UTC。
确认这种稳定性可能与应用有关，而java.util.Date不需要同样的照顾。
b）精确度：ISO-8601可以表达超过毫秒的精度，而java.util.Date和Joda-Time在这里受到限制。如果您以后可能会想到其他新的时间库（如Java 8中的JSR-310或我自己的库提供纳秒精度），则尤其如此。然后，只要它们不是CHAR或VARCHAR，您就会遇到所有JDBC类型java.util.Date和数据库列的精度问题。
一个引人注目的例子是JDBC类型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只是一个很长的包装。
答案 1 :(得分：1)
java.util.Date的优点：稳定查询（不等式和相等），存储大小以及与具有本机日期表示的其他GAE语言的互操作性。