ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Kukushkin <kukushkinale...@gmail.com>
Subject Interoperable Ignite.NET Dates
Date Mon, 02 Nov 2020 21:13:13 GMT

What do you think about changing .NET API to read/write portable dates by
default and making that really portable?

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

*The Proposal*

   1. Always write .NET dates as portable Ignite dates: get rid of the
   BinaryReflectiveSerializer.ForceTimestamp flag that currently triggers this
      - We could still keep the ForceTimestamp flag if saving .NET dates as
      transparent objects seems a useful case. We do not think it is useful.
   2. Automatically convert Local dates to UTC and back *inside*
      - In this case we lose the DateTime.Kind of UTC dates: we write a UTC
      date but we would read a Local date since Ignite would always convert UTC
      to Local when reading.
      We could add a UtcDate date flag to QuerySqlFieldAttribute
      and BinaryReflectiveSerializer to control the deserialization behavior if
      keeping dates in UTC format use case seems important.
   3. Use NodaTime <https://nodatime.org/> for UTC<->Local conversions.
   Noda time uses Java calendars making the conversion truely portable.

*The Benefits*

   1. We think portable dates are much more important than storing time
   zone info. Why do we store time zones for every date on the server anyway?
   Time zone is client-side info.
   2. Simpler application code: no more manual configuration to trigger the
   portable behavior.
   3. 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.

Thank you!

Best regards,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message