Google Datastore - Storing dates as ISO 8601 Strings vs java.util.Date

Question

I am using Joda-Time and I have noticed that DateTime is stored as a java.util.Date in the Google App Engine Datastore for Java, while LocalDateTime is stored as a ISO 8601 compliant String.

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

I know that java.util.Date is a native type of the Datastore.

Is there any particular advantages is storing date/times as a java.util.Date as compared to a ISO 8601 compliant String or is it all the same. When I say advantage I might consider differences in regards to ...

• Inequality queries
• Storage size
• Read/write cost
• etc.

Answer 1

The accepted answer is not wrong, but I would like to add extra details which give a more balanced view.

a) Stable queries : ISO-8601 is stable as long as you assert that

• you only use one date format for storage (ISO defines three: calendar date, ordinal date and week date)

• and that you always use one precision degree for the time part (for example always in milliseconds)

• and that you always use UTC with respect to global timestamps (that is zero offset with symbol Z).

Confirming this kind of stability can be application-dependent while java.util.Date does not require the same care.

b) Precision : ISO-8601 can express more precision beyond milliseconds while java.util.Date and Joda-Time are limited here. This is particularly true if you might later think of other new time libraries like JSR-310 in Java 8 or my own one which provide nanosecond precision. Then you will have precision issues with all JDBC types, java.util.Date and the database columns as far as they are not CHAR or VARCHAR.

A striking example is the JDBC-type java.sql.Time whose precision is limited to seconds, not better. This is pretty much in contrast to the new Java8-type java.time.LocalTime which offers nanoseconds. And worse: This aspect is also relevant for Joda-Time and java.util.Date in your application layer.

For rather academic purposes: Leapseconds can only be stored in ISO-8601-format, not with java.util.Date or similar.

c) Storage size : Of course, java.util.Date has a more compact representation, but else I have to say that disk space is cheap nowadays, so this is not an item to worry about so much.

d) Read-Write-costs : This item is in favor of compact data types like java.util.Date . But you have also to consider that even in this case you have to represent it in a human-readable format in any other layer sooner or later (most in logging or in representation layer). So for data exchange with other proprietary applications which expect java.util.Date this native type is okay, but for logging purposes or XML-data exchange ISO-8601 is probably the better format.

And if you really care so much about performance costs, you might even consider a number type (long - 64 bit) to avoid garbage burdens by unnecessary object creation (in extreme edge cases). Remember: java.util.Date is just a wrapper around a long.

Answer 2

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