Yakov, this could work in .Net where you have real generics. But it will not work in Java in general case due to type erasure - you simply cannot infer the type.
Let's look closely to this: Date Java: 10^-3 Timestamp Java: 10^-9 DateTime .Net: 10^-7 What we see here, is that mapping Java Date to .Net DateTime is alomst certainly a bad thing because we loos too much data. But interoping between Timestamp and DateTime is more or less sensible, we loose only 0.1-s of microseconds. I would suggest the following solution: 1) Fully decouple Date and Timestamp in Java. These are completely different types from Java perspective, H2 perspective (see GridH2Date, GridH2Timestamp), any data database perspective, etc.. 2) Map .Net DateTime to Java Timestamp with warning about possible precision loss. Vladimir. On Tue, Oct 6, 2015 at 1:08 PM, Yakov Zhdanov <yzhda...@apache.org> wrote: > 2015-10-06 12:45 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > On Tue, Oct 6, 2015 at 2:42 AM, Vladimir Ozerov <voze...@gridgain.com> > > wrote: > > > > > 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. > > > > > > > Agree, current design is not ideal. Vladimir, do you have other > > suggestions? > > > how about writing at max precision possible (+ proper type ID) and > interpreting binary data on read depending on (a) portable reader method > call or (b) on actual field type. > > --Yakov >