Igniters, 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 <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 Proposal* 1. Always write .NET dates as portable Ignite dates: get rid of the BinaryReflectiveSerializer.ForceTimestamp flag that currently triggers this behavior. - 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* Ignite.NET. - 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, Alexey
