Possible loss of DateTime's Kind with DotNetclient

[zelenij]

I'm trying to upgrade my code to everything latest, .net8 and all fable related stuff, including Fable.Remoting. In one of my tests I'm checking if a certain server call returns a UTC Kind in a DateTime. It fails, because Kind is Local. This used to work with an older version of the library. I've checked the server side code and I can see that Kind is indeed UTC. Could it be that the value is lost in serialisation/deserialisation?

[Zaid-Ajaj]

Could it be that the value is lost in serialisation/deserialisation?

Hi there @zelenij
Yes, it is possible that Kind is lost when sent across the wire. However, for the longest time I can remember, we recommend using DateTimeOffset if you care about if you care about UTC vs. Local which will maintain its offset when sent/received from either server or client.

Hope this helps!

[zelenij]

I saw the advise regarding DateTimeOffset. Unfortunately, DateTime is all over my codebase, and changing it would be a huge pain. All my times are in UTC, so DateTimeOffset is not strictly necessary.

[Zaid-Ajaj]

@zelenij Alright, let's find out why this happens. Since you are using the dotnet client, it means that both client and server use Fable.Remoting.Json to handle all JSON-related things. In my unit test for a universal DateTime, I see this:

testCase "Union with DateTime conversion" <| fun () ->
    let dateInput = DateTime.Now.ToUniversalTime()
    let serialized = serialize (UnionWithDateTime.Date dateInput)
    let deserialized = deserialize<UnionWithDateTime> serialized
    match deserialized with
    | Int _ -> fail()
    | Date dateOutput ->
        Expect.equal dateInput.Second dateOutput.Second "Seconds are the same"
        Expect.equal dateInput.Minute dateOutput.Minute "Minutes are the same"
        Expect.equal dateInput.Hour dateOutput.Hour "Hours are the same"
        Expect.equal dateInput.Day dateOutput.Day "Days are the same"
        Expect.equal dateInput.Month dateOutput.Month "Months are the same"
        Expect.equal dateInput.Year dateOutput.Year "Year are the same"
        Expect.equal dateInput.Kind dateOutput.Kind "Kinds are the same"

Which shows that the Kind is maintained when serialized then deserialized to JSON.

In the dotnet client, we do use specific settings where we set DateParseHandling to None which should be fine actually, since the default behaviour is lossy:

/// Parses a JSON iput string to a .NET type using Fable JSON converter
let parseAs<'t> (json: string) =
    let options = JsonSerializerSettings()
    options.Converters.Add converter
    options.DateParseHandling <- DateParseHandling.None
    JsonConvert.DeserializeObject<'t>(json, options)

Any chance you could provide an example of a DateTime roundtrip that reproduces the issue?

[zelenij]

Thanks, I'll do more debugging on my side to see if I can clearly rule out any other option and/or create a small standalone test to reproduce the problem

[zelenij]

So far I can see that by server side code prepares a DateTime with Utc Kind. However, when it arrives serialised through the HTTP request via the DotNetClient, it looks like this:

"2024-07-16T15:57:10.9807420Z"

If I read the deserialiser code correctly, it then calls DateTime.Parse on this string. And the result has Local Kind:

Maybe the Json serialisation is at fault here?

[kerams]

I think the solution could be DateTime.Parse (x, CultureInfo.InvariantCulture, DateTimeStyles.RoundtripKind). See The return value and DateTime.Kind https://learn.microsoft.com/en-us/dotnet/api/system.datetime.parse?view=net-8.0#remarks

[Zaid-Ajaj]

@kerams does this still require revisiting?

[kerams]

I don't think anything's changed in this area in the meantime, so likely yes.