no conversion between java.sql.Date and LocalDate

[Heliosmaster]

I see no reason why there should not be a conversion between these two types.

The following code serve the purpose:

(defn from-sql-date [^java.sql.Date date]
  (.toLocalDate date))
(defn to-sql-date [^java.time.LocalDate date]
  (java.sql.Date/valueOf date))

What do you think?

[dm3]

I've thought about it before and I think you're right. However, due to the way conversions work in the library, we need to think about it more carefully.

This conversion loses information when going java.Date -> LocalDate, which is fine, and gains implicit information (time zone) when going the other way. I'm trying to avoid the implicit conversions of this kind whenever possible.

I definitely think it would be beneficial having j/to-java-date, j/to-sql-date and j/to-sql-timestamp go through the same conversion mechanism the other temporal entities use. This way you could say (j/to-sql-date (j/local-date 2017 1 1) "UTC") instead of going through j/instant. Currently the best you can do is (j/to-sql-date (j/instant (j/local-date 2017 1 1) "UTC")).

[Heliosmaster]

I agree with you, and from the java types you're definitely right (about gaining and losing implicit information).

What makes this a bit of an awkward situation is that the "real" SQL date type (for example in PostgreSQL, does not have a timestamp even though java.sql.Date has one. So in my mind, it was

LocalDate <-> java.sql.Date <-> SQL Date

and even though in between some implicit information is added and removed, it turns out fine at both ends. But i agree that we need to think about it carefully :(

[dm3]

@Heliosmaster - I've added a few more functions/conversions. Do you think we can close the issue now?

[Heliosmaster]

Yeah thanks the issue can be closed :)