[
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252711#comment-17252711
]
Nikolay Izhikov commented on IGNITE-12824:
------------------------------------------
> I propose to add yet another BinaryConfiguration flag - WriteDateTimeAsUtc,
> defaults to false. This way we preserve backward compatibility by default.
What kind of compatibility do you have in mind?
For now, we disallow to write Local dates to the Ignite so there is not current
behavior for local dates
> we lose Kind flag
It's true, we always read UTC date from the Ignite.
My understanding this is correct behavior.
Why do you think it's wrong?
My opinion based on the following quote from the documentation [1]
> DateTime can be Local and UTC; Java Timestamp can only be UTC.
[1]
https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility
> 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)
