I'll look into it, but for the most part, Datomic is not OpenSource. Do you envision problems converting to/from date? Can I rely on the round trip being consistent?

Thanks

On Monday, December 9, 2013, Stephen Colebourne wrote:
Storing as a string is reliable, but not ideal for any operation other
than storing/reading. If you can change Datomic why not edit the core
to have dedicated types that match JSR-310 based on ints? ie. research
how dates are stored in other DBs like Postgres.
Stephen

On 9 December 2013 22:21, Rafael de F. Ferreira
<public@rafaelferreira.net> wrote:
> Thanks for your replies.
>
> I'm using the Datomic database from Clojure. It is quite far from
> tradicional RDBMS, so JDBC can't help. I'm on threeten backport.
>
> Currently we are mapping to and from java.util.Dates, but I'm afraid to be
> bitten by j.u.Date's bugs and overall strangeness. We already saw a bug in
> our codebase when mapping from Dates to YearMonths; the call to
> Date.getMonth would return different values depending on which TZ the
> machine was running. We fixed this one by not calling anything on Date and
> converting from j.u.Date -> threeten.LocalDate -> threeten.YearMonth; but
> I'm afraid of what else might be lurking.
>
> If we always start with a LocalDate, then subsequently convert it to and
> from j.u.Dates, is it guaranteed that we will always get the same LocalDate
> we started with? Can TZs or DST affect the conversion?
>
> Has anyone ever did the "packing-into-a-long" option?
>
>
> --
> Rafael de F. Ferreira.
> http://www.rafaelferreira.net/
>
>
> On Mon, Dec 9, 2013 at 4:09 PM, jonaqua@gmail.com <jonaqua@gmail.com> wrote:
>>
>> If you happen to be using JPA, I came across this open Jira item for
>> JPA/threeten support:
>> https://java.net/jira/browse/JPA_SPEC-63
>>
>> I'm using threetenbp in a small JPA project right now and simply
>> converting to java.sql.Date/Timestamp for persistence purposes (not for any
>> business logic).  It's fairly cumbersome since, as far as I know, JPA
>> doesn't seem to support User Types like pure Hibernate so I have to use
>> method level annotations and include some JPA baggage like this:
>>
>>     @Column(name = "some_date")
>>     protected Date getJpaSomeDate() {
>>         return localDateToJpaDate(someDate);
>>     }
>>
>>     protected void setJpaSomeDate(Date someDate) {
>>         this.someDate = localDateFromJpaDate(someDate);
>>     }
>>
>>     @Transient
>>     public LocalDate getSomeDate() {
>>         return someDate;
>>     }
>>
>>
>>
>> On Mon, Dec 9, 2013 at 12:16 PM, Douglas Surber
>> <douglas.surber@oracle.com> wrote:
>>>
>>> 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
>>>
>>>
>>>
>>> At 08:57 AM 12/9/2013, Rafael de F. Ferreira wrote:
>>>
>>> >Are there guidelines established for persisting threeten classes to
>>> >databases? For the purposes of this question we can separate date
>>> >and time classes in three categories:
>>> >    * Timestamps: only the Instant class, representing a point in a
>>> > timeline
>>> >    * Unanchored: recurring time specifications such as MonthDay and
>>> > LocalTime
>>> >    


--
--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/