Unwanted additional double quotes after fetching date string - why?

Unity Services
, ,
1

Hello, I’m struggling to save a date and then turning it back into a DateTime object.

I first create the date string like this:
DateTime.Now.ToString(“O”);

Which logs as: 2022-09-02T14:22:30.8706876+02:00

In the Cloud Save player data dashboard It still looks right to me:

1192×386 16.5 KB

(also if I try to edit it, it does not yet have additional double quotes)

But when I then fetch the data again: CloudSaveService.Instance.Data.LoadAllAsync(); it comes wrapped in additional double quotes

{
  ...
  "MY_DATE_KEY": "\"2022-09-02T14:22:30.8706876+02:00\"",
}

and is now logged as: “2022-09-02T14:22:30.8706876+02:00”

  • which gives me: FormatException: String was not recognized as a valid DateTime - when I try to convert it back into a DateTime object, I assume because of the unwanted double quotes.

Of course I can remove the double quotes from the string to move on, but I’d like to understand why they appear? I also save other data as string, for example “123123” logs: 123123, and is fetched: { “OTHER_KEY”: “123123” } and still is logged: 123123 - no additional double quotes added here.

So why is it that the date string is treated differently?

And please note that in the cloud save dashboard, there are no additional double quotes as the screen snippet above shows, it seems like they are applied when fetching:
CloudSaveService.Instance.Data.LoadAllAsync()

Thanks!

2

Hi there,

Since you’re using DateTime.Now.ToString(“O”) the data type that you’re saving is actually a string and no longer a DateTime object. Because of this the JSON serializer inside the CloudSave SDK will have to add " around it in order to not accidentally break the Json serialization, if you simple send through the DateTime object itself it should get rid of the extra quotes and work as expected

Hope this helps

1 Like
3

After a quick conversation internally we decided to mark this as a bug still as saving a string shouldn’t add the quotes to the final result once retrieved through the SDK. It’s still best to store the object itself in this case rather than a stringified version of it

4

Thanks for the update !