You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Pavel Tupitsyn (Jira)" <ji...@apache.org> on 2021/03/11 14:31:00 UTC
[jira] [Updated] (IGNITE-12824) .NET: Interoperable DateTime
[ https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Tupitsyn updated IGNITE-12824:
------------------------------------
Labels: .NET sbcf (was: .NET iep-54 ignite-3 sbcf)
> .NET: Interoperable DateTime
> ----------------------------
>
> 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, sbcf
> Fix For: 3.0, 2.10
>
> Attachments: IGNITE-12824-from-2.9.0.patch
>
> Time Spent: 2.5h
> 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)