On 06.10.2015 12:26, Vladimir Ozerov wrote: > 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.
>From the peanut gallery ... it seems like a really bad idea to design a marshalling format based on what some language standard library happens to provide. IMO, the way to do this is to define your own max precision timestamp type, marshal it at full precision, and provide conversions to standard types. That way your users can choose to use your type which provides full precision on all platforms, or decide to use the standard types with the potential loss of precision that entails; but it becomes *their* decision, not a limitation set by the library. -- Brane > 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 >>
