Google数据存储-将日期存储为ISO 8601字符串与java.util.Date

Question

我正在使用Joda-Time，并且已经注意到DateTime在Java的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的String相比，将日期/时间存储为java.util.Date有什么特别的优点吗？或者都是一样的。 当我说优势时，我可能会考虑在...方面的差异。

• 不平等查询
• 收纳尺寸
• 读写成本
• 等等

Answer 1

公认的答案是正确的，但我想补充一些额外的细节，以使观点更加平衡。

a） 稳定的查询 ：只要您断言ISO-8601是稳定的

• 您仅使用一种日期格式进行存储（ISO定义了三种：日历日期，序号日期和星期日期）

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

• 并且您始终相对于全局时间戳使用UTC（即，符号Z为零偏移）。

确认这种稳定性可能与应用程序有关，而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相反。 更糟糕的是：这方面也与应用程序层java.util.Date Joda-Time和java.util.Date有关。

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

c） 存储大小 ：当然， java.util.Date具有更紧凑的表示形式，但是我不得不说当今磁盘空间很便宜，因此不必担心太多。

d） Read-Write-costs ：此项赞成紧凑数据类型，如java.util.Date 。 但是，您还必须考虑到即使在这种情况下，您也迟早必须以任何其他层（在日志记录层或表示层中）以人类可读的格式表示它。 因此，与期望使用java.util.Date其他专有应用程序进行数据交换时，可以使用此本机类型，但是出于日志记录目的或XML数据交换， ISO-8601可能是更好的格式。

而且，如果您真的非常在意性能成本，则甚至可以考虑使用数字类型（长-64位），以避免不必要的对象创建（在极端情况下）而造成垃圾负担。 记住： java.util.Date只是一个长包装。

Answer 2

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