0
votes

I have documents with string fields that contain DateTimeOffset values. For example:

public class DateTimePocoDocument : Resource
{
    public string startTime { get; set; }
    public string endTime { get; set; }     
}

Imagine a string value being set as follows.

myDateTimePocoDocument.startTime = DateTimeOffset.UtcNow.ToString("o");

Documents are created in DocumentDb using the .NET DocumentClient.

 public async Task<Document> InsertAsync(TDocument data)
 {
     return await Client.CreateDocumentAsync(Collection.SelfLink, data);
 }

Viewing the document in DocumentDb shows the string fields properly stored.

[
  {
    "startTime": "2016-10-01T13:00:00.0000000+00:00",
    "endTime": "2016-10-01T14:35:17.215947+00:00",
    "id": "2b6e53e1-2099-41f8-8405-f9daf750cfc8",
    "_rid": "6qt9AJ0xkgDkAwAAAAAAAA==",
    "_self": "dbs/6qt9AA==/colls/6qt9AJ0xkgA=/docs/6qt9AJ0xkgDkAwAAAAAAAA==/",
    "_etag": "\"3d00c96d-0000-0000-0000-586e67b40000\"",
    "_attachments": "attachments/",
    "_ts": 1483630513
  }
]

I do this because I want to manually handle all serialization and deserialization of DateTimeOffset values. I need precision and predictability as data moves across controllers, gets serialized to Azure App client, gets serialized into SQLite and back, etc, etc.

When I execute a query as follows:

Client.CreateDocumentQuery<TDocument>(Collection.DocumentsLink, query, new FeedOptions { EnableScanInQuery = true, EnableCrossPartitionQuery = false });

The documents return the startTime string above as "10/01/2016 13:00:00". I've created a custom JsonConverter and attached it to the property to see what was being assigned to the string property. The converter confirms that a DateTime is being assigned to the string field. The DocumentDb client is choosing to treat the string as a date value because it looks like a date. Unfortunately that results in a changed string value in this case. Why is it performing that translation on my string and how can I prevent that without having to customize the string?

Thanks

1
I recommend that you store all dates in DocumentDB as ISO-8601 strings with Zulu time (meaning no offset), so 2016-10-01T13:00:00.000Z. This will preserve your ability to do range queries. It might require you to shift the literals that you use to compose those queries from user time to Zulu time but there are a number of libraries to do that for you. - Larry Maccherone
Gerard, I doubt DocumentDB will do that as it has treats strings as strings and shouldn't perform any such modifications. If your POCO contains a DateTimeOffset property, I can imagine that being displayed as the 10/01/2016 13:00:00 as that's the default deserialization setting for DateTimeOffset. Can you please confirm this? Also, please provide the POCO and tell us how are you creating the Document in DocumentDB. - Rajesh Nagpal
As requested, I have added an example POCO and how documents are created. I don't want the focus to be on searchability as I already have that so I removed it from the question. - Gerard MC
Thanks Gerard for the info! I'll try to debug this and get back to you soon. - Rajesh Nagpal

1 Answers

0
votes

Looks like Azure Cosmos DB doesn't support DateTimeOffset type yet. The request for such support is already filed and can be tracked here.