[
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-12824:
--------------------------------------
Description:
*+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+*
# 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.
# 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.
# Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda time
uses Java calendars making the conversion truely portable.
*+The Benefits+*
# 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.
# Simpler application code: no more manual configuration to trigger the
portable behavior.
# 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.
was:Presently BinaryReflectiveSerializer serialises .NET dates Ignite objects
by default. This could be changed by either setting
BinaryReflectiveSerializer.ForceTimestamp property to "true" or adding
"QuerySqlField" attribute to Date fields. I have multiple Ignite/GridGain users
using this functionality and all of them are confused with this default
behavior. Let's see if we can change the default behavior to save .NET dates in
interoperable Ignite TIMESTAMP format, converting them to UTC dates inside
BinaryReflectiveSerializer so that the users do not have to do the
ToUniversalDate conversion manually.
> Interoperable Ignite.NET Dates
> ------------------------------
>
> Key: IGNITE-12824
> URL: https://issues.apache.org/jira/browse/IGNITE-12824
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
> Affects Versions: 2.8
> Reporter: Alexey Kukushkin
> Assignee: Alexey Kukushkin
> Priority: Major
> Labels: .NET, ignite-3, sbcf
> Fix For: 3.0
>
> Attachments: ignite-12824-vs-2.8.patch
>
>
> *+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+*
> # 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.
> # 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.
> # Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda
> time uses Java calendars making the conversion truely portable.
>
> *+The Benefits+*
> # 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.
> # Simpler application code: no more manual configuration to trigger the
> portable behavior.
> # 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
