Alexey, Just to clarify before we start the discussion: this proposal seems to introduce some breaking changes, so we are talking about Ignite 3.0, correct?
Pavel On Tue, Nov 3, 2020 at 12:13 AM Alexey Kukushkin <kukushkinale...@gmail.com> wrote: > Igniters, > > What do you think about changing .NET API to read/write portable dates by > default and making that really portable? > > *The Problem* > Presently .NET API writes dates as composite Ignite objects. Only .NET > clients can read such dates: any other client (JDBC, Java, etc) does not > understand it without custom deserialization. > > It is still possible to configure .NET serialization to write dates as > Ignite dates - see DateTime Serialization note > < > https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility > >. > But then Ignite accepts only UTC dates, requiring the application > developers to convert local dates to UTC dates and back. This task is not > trivial: DateTime.ToUniversalTime > < > https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1 > > > uses > calendars different from Java (and the .NET calendars are the invalid ones > - especially for pre-1990 dates). > > The motivation for the current default behavior was probably the desire to > keep the Time Zone information: Ignite dates do not store time zones. > > In our experience interoperability is more important than storing time zone > info. > > *The Proposal* > > 1. Always write .NET dates as portable Ignite dates: get rid of the > BinaryReflectiveSerializer.ForceTimestamp flag that currently triggers > this > behavior. > - We could still keep the ForceTimestamp flag if saving .NET dates as > transparent objects seems a useful case. We do not think it is > useful. > 2. Automatically convert Local dates to UTC and back *inside* > Ignite.NET. > - In this case we lose the DateTime.Kind of UTC dates: we write a UTC > date but we would read a Local date since Ignite would always > convert UTC > to Local when reading. > We could add a UtcDate date flag to QuerySqlFieldAttribute > and BinaryReflectiveSerializer to control the deserialization > behavior if > keeping dates in UTC format use case seems important. > 3. Use NodaTime <https://nodatime.org/> for UTC<->Local conversions. > Noda time uses Java calendars making the conversion truely portable. > > *The Benefits* > > 1. We think portable dates are much more important than storing time > zone info. Why do we store time zones for every date on the server > anyway? > Time zone is client-side info. > 2. Simpler application code: no more manual configuration to trigger the > portable behavior. > 3. Non-trivial code to make the truly portable UTC<->Local conversion is > implemented once inside Ignite instead of having every Ignite.NET > application implementing it. > > Thank you! > > -- > Best regards, > Alexey >
