[ 
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254491#comment-17254491
 ] 

Pavel Tupitsyn commented on IGNITE-12824:
-----------------------------------------

[~nizhikov] PR looks good to me, thanks!

> .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, iep-54, ignite-3, sbcf
>             Fix For: 3.0
>
>         Attachments: IGNITE-12824-from-2.9.0.patch
>
>          Time Spent: 2h 20m
>  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)

Reply via email to