FeedIterator corrupts dates in strings and collections of strings.

[vzubariev]

Describe the bug

 class A
 {
      ...
       string Date { get; set; }
       Dictionary<string, string> Parameters { get; set; }
       List<string> List { get; set; }
 }

If a date stored in a string field or in any collection of strings (refer class example above), after fetching documents using FeedIterator, all dates change their representation losing precision and time zone information.

If in Cosmos DB a date looks like "2021-02-17T18:41:10.8590000Z", after reading it become "02/17/2021 18:41:10".

When using a ReadItemAsync API, the item retrieved correctly.
When using a FeedIterator after any of GetItemLinqQueryable or GetItemQueryIterator APIs the dates retrieved corrupted.

After adding a custom serialization attribute for Date field, noticed, the ReadJson method already getting DateTime value, not a string. Specifying a proper output format in DateTime.ToString, I was able to work around for the string field. But I still have no ideas how to fix the case with collections.

Setting a custom serializer not works, SDK ignores it for those APIs.

It feels out Cosmos SDK uses DateTime.ToString without parameters for such cases, but I failed to find where in code.

To Reproduce

Insert an item with date string to container.
Select all items from container using GetItemLinqQueryable or GetItemQueryIterator APIs.

Expected behavior
Ideally the string should be in the same form as in the DB.
At least it should follow ISO format used by Newtonsoft and Cosmos DB:
https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/working-with-dates#storing-datetimes

Actual behavior
Selected string has date in different format and precision than in DB.

Environment summary
SDK Version: 3.28.0 and below.

[ealsur]

@aavasthy Can you take a look at this report? This seems related to the default way Newtonsoft.Json treats dates: JamesNK/Newtonsoft.Json#862 but it's worth double checking

[vzubariev]

If the source json given to Newtonsoft.Json's JsonConvert.DeserializeObject, it will deserializing it right, at least for our ISO UTC dates representation.

A workaround we use in a critical place is to read to Microsoft.Azure.Documents.Document's, then iterate each, call document.ToString() to produce the json back, which appears not damaged, and then use JsonConvert.DeserializeObject on a top. But in this way we do serialization / deserialization of each object 3 times, which is not efficient, also sticks us to using the Document from V2 SDK.