ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Kukushkin <kukushkinale...@gmail.com>
Subject Re: Interoperable Ignite.NET Dates
Date Tue, 03 Nov 2020 08:04:49 GMT
Pavel,

We propose changing public API so this is for Ignite 3.0.

Thanks!

вт, 3 нояб. 2020 г. в 02:17, Pavel Tupitsyn <ptupitsyn@apache.org>:

> 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 <
> kukushkinalexey@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
> >
>


-- 
Best regards,
Alexey

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message