Realm-dotnet: DateTimeOffset offset reset after being persistance

[Arminkhodaei]

Goals

A DateTimeOffset Offset property gets reset after the RealmObject becomes persistence!

After calling DateTimeOffset.Now I have a DateTime with the right offset like {2/24/2019 12:51:31 PM +03:30}. But, after being persistence using Add method and fetching it again, the value will be like {2/24/2019 12:51:31 PM +00:00}

Expected Results

{2/24/2019 12:51:31 PM +03:30}

Actual Results

Offset property without the right value:
{2/24/2019 09:21:31 PM +00:00}

Steps to Reproduce

1) Read from DateTimeOffset.Now and set it to the RealmObject
2) Add the object to the realm instance

Version of Realm and Tooling

• Platform: Xamarin Forms 3.4
• Realm .Net: v3.3.0
• Flavor:
  
  
  
  • Self-Hosted
  
  
• Client OS & Version: Android 6.0 Marshmallow

[nirinchev]

The offset property being reset is not surprising - the dates stored in the database are in UTC. What is surprising though is that the time doesn't change. I would expect that to be adjusted to represent the same moment in the new timezone.

[Arminkhodaei]

The offset property being reset is not surprising - the dates stored in the database are in UTC. What is surprising though is that the time doesn't change. I would expect that to be adjusted to represent the same moment in the new timezone.

Oops. That also has changed to UTC. Sorry about that.
So, I have to convert it to the right time zone after each query?

[Arminkhodaei]

As a developer I expect it to have the same value as I passed to it. To be honest, I think that forces me to do an extra conversion. At least we could pass the time zone as a configuration. Anyway, thanks for your help.

[realm-probot[bot]]

Hey - looks like you forgot to add a T:* label - could you please add one?

[nirinchev]

The reason the timezone information is not persisted is because the underlying data type is Int64 and there's no way to encode timezone information in there (I believe the DateTimeOffset struct itself is 10 bytes).

We haven't made significant efforts to resolve that because
1) it's typical for databases to store dates in UTC (probably a leftover from SQL times where writing a query without taking timezones into account was much easier).
2) a consumer is likely to want to convert the dates to a single timezone anyway - e.g. an app that shows dates will be super confusing if they were in different timezones and the user had to figure out which is when.

If you have the rare case when timezone info is very important, then we'd recommend that you encode it in an additional field on the model.

[Arminkhodaei]

That makes sense. You are right. In the most of the cases, an application needs to work in a specific time zone, otherwise the offsets ticks can be stored as another property with the type of long or something like that.
I just confused about eliminating the time zone information and your explanation makes me understand its reason. Thanks.