[IGNITE-12824] .NET: Interoperable DateTime

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.8
• Fix Version/s: 3.0, 2.10
• Component/s: platforms
• Labels: .NET sbcf
• Release Note: .NET: Add BinaryConfiguration.TimestampConverter to allow custom user-defined timezone conversion logic
• Ignite Flags: Docs Required, Release Notes Required
• Assignee: Nikolay Izhikov
• Reporter: Alexey Kukushkin
• Created: 22/Mar/20 21:13
• Updated: 11/Mar/21 14:30
• Resolved: 24/Dec/20 12:02

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. 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 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

1. 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.
2. 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.
3. Use NodaTime for UTC<->Local conversions. Noda time uses Java calendars making the conversion truly portable.

 
The Benefits

1. 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.
2. 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
• IEP-TBD

Issue Links

• blocks: IGNITE-12825 Serialize Java and .NET dates using same calendars
• relates to: IGNITE-12859 .NET: Services fail to call method with DateTime or Guid argument
• relates to: IGNITE-13865 .NET: DateTime can't be used as a cache key or value
• links to: GitHub Pull Request #8568
• links to: IEP-54: Schema-first Approach