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

.NET: Interoperable DateTime

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.8
    • 3.0, 2.10
    • platforms
    • .NET: Add BinaryConfiguration.TimestampConverter to allow custom user-defined timezone conversion logic
    • 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

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            nizhikov Nikolay Izhikov
            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

                Slack

                  Issue deployment