-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serialization of DateTime loses Kind and TimeZone #273
Comments
Hi @MikaelUmaN, In order not to lose the time zone information it is recommended to use As for the Kind, I believe we had that implemented before but I need to double check |
Hi. Thanks for feedback. I can confirm that DateTimeOffset works as expected, except it loses "kind" information. It is set to Unspecified. I still think it would be nice to have DateTime working as well, though. Note that I am just trying to pass dates and not actually times; so it's doubly confusing that the server-side receives another date when transferring a DateTime. The cleanest solution I think is to do it the way MessagePack does it; and just always rely on UTC when transferring; for example by going to ToUniversalTime and using Ticks. From my side I will use DateTimeOffset as a workaround until DateOnly arrives in net 6.0 GA. Thanks for an excellent library. |
Yes you are right of course, it does not have Kind. Sorry my mistake, it was because I converted it myself and looked at it. The comment on DateTime still stands though. However, for my purposes you can close this issue in case it's not prioritized to fix. |
I think we can resolve this issue by documenting the current behavior and recommending people to use |
Hi.
This should be related to: Zaid-Ajaj/Fable.SimpleJson#21 and #108
Setup
Expected
Actual
Why this is a problem for me
Basically I am on dotnet 5 and eagerly awaiting the "DateOnly" struct.
As it is now, I expect to be able to send string(myDateParameter) to an external http API on the server-side but instead of todays date (e.g. 2021-10-12) I get yesterdays.
Suggestions
Probably it's not possible to keep the "Kind" type across serialisation, but then I think it should explicitly call "ToUniversalTime" prior to serialization and explicitly read it as Kind=UTC on the server side when deserializing.
The the application layer can handle the rest.
The text was updated successfully, but these errors were encountered: