ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Interoperable Ignite.NET Dates
Date Mon, 02 Nov 2020 23:17:02 GMT
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
>

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