我正在使用 Joda-Time，我注意到 DateTime 在 Google App Engine Datastore for Java 中存储为 java.util.Date，而 LocalDateTime 存储为符合 ISO 8601 的字符串。
我知道 java.util.Date 是 Datastore 的原生类型。
与符合 ISO 8601 的字符串相比，将日期/时间存储为 java.util.Date 是否有任何特别的优势，或者是否都一样。当我说优势时，我可能会考虑...
【问题讨论】：
标签： java google-app-engine jodatime objectify iso8601
接受的答案没有错，但我想添加额外的细节，以提供更平衡的观点。
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 类型的java.sql.Time，它的精度被限制为秒，而不是更好。这与提供纳秒的新 Java8 类型 java.time.LocalTime 形成鲜明对比。更糟糕的是：这方面也与应用层中的 Joda-Time 和 java.util.Date 相关。
出于学术目的：闰秒只能以 ISO-8601 格式存储，不能以 java.util.Date 或类似格式存储。
c) 存储大小：当然，java.util.Date 有一个更紧凑的表示，但是我不得不说现在磁盘空间很便宜，所以这不是一个需要担心的项目所以很多。
d) Read-Write-costs：此项支持紧凑型数据类型，例如java.util.Date。但是您还必须考虑，即使在这种情况下，您迟早必须在任何其他层（大多数在日志记录或表示层）中以人类可读的格式表示它。因此，对于与期望java.util.Date 的其他专有应用程序进行数据交换，这种 native 类型是可以的，但对于 日志记录或 XML 数据交换，ISO-8601 可能是更好的格式.
如果您真的非常关心性能成本，您甚至可以考虑使用数字类型（长 - 64 位）来避免不必要的对象创建（在极端情况下）造成的垃圾负担。请记住：java.util.Date 只是一个 long 的包装。
【讨论】：
java.util.Date 的优势：稳定的查询（不等式和等式）、存储大小以及与具有本地日期表示的其他 GAE 语言的互操作性。
【讨论】：