Uploaded image for project: 'Ignite'
  1. Ignite
  2. IGNITE-12824

.NET: Interoperable DateTime

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.8
    • Fix Version/s: 3.0, 2.10
    • Component/s: platforms
    • Labels:
    • Release Note:
      .NET: Add BinaryConfiguration.TimestampConverter to allow custom user-defined timezone conversion logic
    • Ignite Flags:
      Docs Required, Release Notes Required

      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

        Attachments

        1. IGNITE-12824-from-2.9.0.patch
          8 kB
          Alexey Kukushkin

          Issue Links

            Activity

              People

              • Assignee:
                nizhikov Nikolay Izhikov
                Reporter:
                kukushal Alexey Kukushkin
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 2.5h
                  2.5h