This doesn't answers the question. First, Java Timestamp has greater precision than .Net DateTime, so silent data loss could happen in this case as well. Second, "use timestamp" is defined on class level. It means we cannot handle a class which have both Date and Timestamp fields.
Looks like a bug and/or invalid design for me. On Tue, Oct 6, 2015 at 12:21 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > On Tue, Oct 6, 2015 at 1:39 AM, Pavel Tupitsyn <ptupit...@gridgain.com> > wrote: > > > Keep in mind that separating them can introduce difficulties for other > > platforms. > > For example, DateTime in .Net has more precision (100ns vs 1ms in Java). > > Serializing this in Java format will lead to data loss. Serializing .Net > > DateTime as Timestamp will preserve precision, but may hurt > > interoperability. > > > > Thanks Pavel. This is exactly the reason why Date vs Timestamp selection it > is implemented right now via a configuration flag. > > > > > > Thanks, > > > > On Tue, Oct 6, 2015 at 10:29 AM, Denis Magda <dma...@gridgain.com> > wrote: > > > > > I would definitely remove such a mapping if no one explains a reason we > > > have it. > > > > > > -- > > > Denis > > > > > > > > > On 10/6/2015 10:26 AM, Vladimir Ozerov wrote: > > > > > >> Igniters, > > >> > > >> For some reason we "merged" Date and Timestamp types in portable > > >> marshaller. They are both written in the same format with the same > type > > >> ID. > > >> And how date is interpreted on read side - as Date or as Timestamp - > > >> depends on configuration flag "use timestamp". > > >> > > >> Is there are reason why we do this? Transparent conversion from > > Timestamp > > >> to Date is invalid use case because it leads to data loss. Looks like > we > > >> can separate these types from each other and remove this strange > > >> configuration parameter. > > >> > > >> Thoughts? > > >> > > >> Vladimir. > > >> > > >> > > > > > > > > > -- > > -- > > Pavel Tupitsyn > > GridGain Systems, Inc. > > www.gridgain.com > > >
