[
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252940#comment-17252940
]
Pavel Tupitsyn commented on IGNITE-12824:
-----------------------------------------
> What kind of compatibility do you have in mind?
Sorry, I was wrong here. The only behavior change is that we accept Local
DateTime instead of throwing an exception, so unless some user relies on the
exception (which is crazy), we do not break compatibility.
However, the behavior of "accept Local and UTC, return only UTC" is dangerous
and can lead to subtle bugs in business code.
I understand that some users only work with Local dates and want to convert to
UTC on write and back to Local on read.
Other users may have different needs.
So instead of a flag, I propose to add an extension point:
{{BinaryConfiguration.DateTimeConverter}} of type {{IDateTimeConverter}}:
{code}
public interface IDateTimeConverter
{
DateTime ConvertOnWrite(DateTime dateTime);
DateTime ConvertOnRead(DateTime dateTime);
}
{code}
Thoughts?
> 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: Nikolay Izhikov
> Priority: Major
> Labels: .NET, iep-54, ignite-3, sbcf
> Fix For: 3.0
>
> Attachments: IGNITE-12824-from-2.9.0.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *+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 {{BinaryReflectiveSerializer.UtcDate flag}} to disable this
> conversion. This prevents loosing the {{DateTime.Kind}} property of UTC
> dates. {{UtcDate}} set to true implies the existing behavior: Ignite gets
> UTC dates and throws a "Date must be in UTC" exception on an attempt to write
> a Local date. The {{UtcDate}} flag is false by default.
> # 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.
> +*References*+
> * [Dev-List
> Discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Interoperable-Ignite-NET-Dates-td49946.html]
> * IEP-TBD
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
