Most applications can use the default string representation for DateTime?

[osexpert]

You write:
Most applications can use the default string representation for DateTime for the following reasons:
This approach doesn't require any custom code or attributes for JSON conversion.

Not sure that is true.
Using Netwtonsoft I get different length:

class test
{
DateTime d1;
DateTime d2;
DateTime d3;
}

d1 = DateTime.UtcNow;
d2 = new DateTime(2020, 1, 1, 12, 3, 0, DateTimeKind.Utc);
d3 = DateTime.MinValue.ToUniversalTime();

result of var json = JsonConvert.SerializeObject(t):
"d1": "2020-10-27T12:59:44.9331404Z",
"d2": "2020-01-01T12:03:00Z",
"d3": "0001-01-01T00:00:00Z",

I wish you at least provided example for .NET\C# of how this can work correctly.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: c256dbf4-122d-1569-c4c3-0e401766c712
• Version Independent ID: 747c3f05-167d-2048-6f1b-fa1d7d856f66
• Content: Working with dates in Azure Cosmos DB
• Content Source: articles/cosmos-db/working-with-dates.md
• Service: cosmos-db
• GitHub Login: @SnehaGunda
• Microsoft Alias: sngun

[osexpert]

Newtonsoft.Json 12.0.0.0

[AnuragSharma-MSFT]

@gdalsnes Thank you for the feedback. We are actively investigating and will get back to you soon.

[AnuragSharma-MSFT]

@gdalsnes By the statement "This approach doesn't require any custom code or attributes for JSON conversion", document says that if any date is saved in 'UTC date and time ISO 8601' format they can directly be queried using GetCurrentDateTime function and there should not be any conversion needed on JSON properties.

The code sample (d1 = DateTime.UtcNow) provided by you shows the correct way to store the date in UTC format which can later be used again the GetCurrentDateTime functions in inline queries, stored procedures or triggers. Similar code snippet is shown in the article as well.

Please let me know if this information helps.

[AnuragSharma-MSFT]

@gdalsnes Please let us know if above details helps.

[AnuragSharma-MSFT]

@gdalsnes We will now proceed to close this thread because of lack of response. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.

[osexpert]

No, you completely misunderstand my point.

[osexpert]

For lexical order to work (range search) all times must have same format and length. As my example show, the times are shorter if they have seconds resolution.

[osexpert]

So at least with cosmosdb sdk v2 and newtonsoft default datetime format, this does not always produce the recomendee fixed lenght format yyyy-MM-ddTHH:mm:ss.fffffffZ

[osexpert]

It is probably related to this Azure/azure-cosmos-dotnet-v3#1468
This seems to be for v3 SDK and System.Text.Json, so the problem is both in SDK v2 and v3 and with both Newtonsoft json and System.Text.Json, so clearly this should have been fixed inside CosmosDB itself (uniform and fixed length datetime format).

Having documentation telling this is a piece of cake and will just work out of the box does not help, as this is almost bloody impossible to get right (I have tried for days, still far from a solution).