[
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 Solution+*
# Always write .NET dates as portable Ignite dates: get rid of the
{{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers this
behavior.
Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects
seems a useful case.
# Automatically convert Local dates to UTC and back *inside* Ignite.NET.
Add a {{UtcDate}} date flag to {{QuerySqlFieldAttribute}} and
{{BinaryReflectiveSerializer}} to control the deserialization behavior to
prevent loosing the {{DateTime.Kind}} property of UTC dates.
# Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda time
uses Java calendars making the conversion truly portable.
*+The Benefits+*
# Portable dates is a more frequent use-case than storing time zone info for
every date in Ignite. This becomes default behavior and the developers do not
need to always explicitly configure it.
# 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:
*+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.
> 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
>
>
> *+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 Solution+*
> # Always write .NET dates as portable Ignite dates: get rid of the
> {{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers
> this behavior.
> Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects
> seems a useful case.
> # Automatically convert Local dates to UTC and back *inside* Ignite.NET.
> Add a {{UtcDate}} date flag to {{QuerySqlFieldAttribute}} and
> {{BinaryReflectiveSerializer}} to control the deserialization behavior to
> prevent loosing the {{DateTime.Kind}} property of UTC dates.
> # Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda
> time uses Java calendars making the conversion truly portable.
>
> *+The Benefits+*
> # Portable dates is a more frequent use-case than storing time zone info for
> every date in Ignite. This becomes default behavior and the developers do not
> need to always explicitly configure it.
> # 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)
