I think that java.time.Instant is the best choice to store a date into DB: it is the most likely TIMESTAMP and you are not depending by timezone, it is just a moment on the time.
JPA supports LocalDate, LocalTime, LocalDateTime etc. but not Instant. Sure, you can use either AttributeConverter or some libraries like Jadira but why it isn't supported out of the box?
I'll try this again. There is some discussion in the issue. The latest discussion seems to be:
mkarg said: While that is absolutely correct, the technical answer is a bit more complex: What is the final predicate that makes a data type eligible for inclusion in the set of mandatory type mappings?
One could say, that predicate is "being essential" or "being of common use", but who defines what "essential" or "common use" is? See, for some applications, support for java.awt.Image and java.net.URL might be much more essential than support for LocalDate or ZonedDateTime. On the other hand, other applications might be full of LocalDate but never uses Instant. So where exactly to make the cut? This becomes particularly complex when looking at the sheer amount of types found in the JRE, and it is obvious there has to be a cut somewhere. Even JavaFX, which is bundled with the JRE, does not support Instant still in v8, so why should JPA? And looking at the current progress of Project Jigsaw, possibly the qualifying predicate might simply be answered by "all types in a particular jigsaw module"?
Anyways, it is not up to me to decide. I do support your request, and would love to see support for rather all Java Time API times, particularly for Instant and Duration, and your request has prominent supporters like for example Java Champion Arun Gupa as I learned recently. But I doubt the final answer will be as simple an satisfying as we would love to have it.
Maybe it would be better to simply set up another JSR, like "Common Data Type Conversions for the Java Platform", which provides much more mappings than just date and time, but also would not be bound to JPA but also could be used by JAXB, JAX-RS, and possibly more API that deal which the problem of transforming " to "? Having such a vehicle would really reduce boilerplate a lot.
TL-DR; There are a lot of types. We had to draw the line somewhere.
There is a new issue for it to be added to a future JPA version.
Another interesting bit of analysis I found on a thread by Douglas Surber (works on JDBC):
The JDK 8 version of JDBC includes support for most of the SQL types that correspond to 310 classes.
- DATE - LocalDate
- TIME - LocalTime
- TIMESTAMP WITH OUT TIME ZONE - LocalDateTime
- TIMESTAMP WITH TIME ZONE - OffsetDateTime
JDK 8 version of JDBC does not include a mapping between the INTERVAL types and the corresponding 310 classes.
There is no SQL type that exactly corresponds to any other 310 classes. As a result, the JDBC spec is silent for all other classes.
I would strongly encourage JDBC developers to use the new 310 classes. There are problems with java.util.Date, java.sql.Date, java.sql.Time, and java.sql.Timestamp. You should consider them deprecated. The 310 classes are vastly superior.
Douglas
TL:DR; We just picked one Java 8 type for each of the 4 possible ways you might store temporal data in the database.
Finally, if you read through this thread it appears there is significant cultural pressure to keep standard APIs small and simple.
It's not a JPA issue but a JDBC issue.
JDBC supports Date, Timestamp, LocalDate, LocalTime and LocalDateTime but NOT Instant.
This is not a Java issue but an SQL issue whereby what is stored in the database is year-month-day-hour-minute-second construct.
Think of SQL functions : YEAR() MONTH() etc...
These functions cannot be applied to simple millisencods since 1970 number. They do require a LocalDateTime construct to perform these functions.
来源：https://stackoverflow.com/questions/49309076/why-jpa-does-not-support-java-time-instant