Possible loss of DateTime's Kind with DotNetclient #367

Activity

1. Zaid-Ajaj commented on Jul 12, 2024

   

   Zaid-Ajaj

   on Jul 12, 2024

   Owner

   More actions

   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!
2. zelenij commented on Jul 12, 2024

   

   zelenij

   on Jul 12, 2024

   Author

   More actions

   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.
3. Zaid-Ajaj commented on Jul 12, 2024

   

   Zaid-Ajaj

   on Jul 12, 2024

   Owner

   More actions

   @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?
4. zelenij commented on Jul 14, 2024

   

   zelenij

   on Jul 14, 2024

   Author

   More actions

   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
5. zelenij commented on Jul 16, 2024

   

   zelenij

   on Jul 16, 2024

   Author

   More actions

   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?
6. kerams commented on Mar 21, 2025

   

   kerams

   on Mar 21, 2025

   Collaborator

   More actions

   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
7. Zaid-Ajaj commented on Apr 18, 2026

   

   Zaid-Ajaj

   on Apr 18, 2026

   Owner

   More actions

   @kerams does this still require revisiting?
8. kerams commented on Apr 19, 2026

   

   kerams

   on Apr 19, 2026

   Collaborator

   More actions

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

   👍React with 👍1Reacted by Zaid Ajaj