Saving and reading DateTimeOffset in DocumentDB

[ArjunMenonUK]

Hi,

I am saving some candidate data in Azure DocumentDB with date field as DateTimeOffset as string in the format "2017-01-13T07:30:00+05:30" as per the thread http://stackoverflow.com/questions/31973710/datetime-the-epoch-and-documentdb Document DB supports DateTimeOffset now. But i noticed one thing the data i saved is UTC+5:30 but when i look at the Azure portal its getting saved to UTC by default. Is it an auto conversion done by DocumentDB , because i was able to save data with UTC+5:30 last week , but there was an issue while reading because it was getting converted to UTC. I raised a question in StackOverFlow (StackOverFlow). I am using .NET class DocumentClient to save & read data. Am i missing something?

[ArjunMenonUK]

Any updates on this anyone??/

[rnagpal]

@ArjunMenonUK Can you please provide the sample code for which you are seeing this issue as I couldn't repro this?
Please see https://gist.github.com/rnagpal/8ac56a8af81f31a41a3c28e080e45b70 for the code that I had for creating/retrieving from documentdb as well as seeing in portal as well.

I'm seeing the same value everywhere.

[rnagpal]

@ArjunMenonUK Did you got a chance to try this?

[ArjunMenonUK]

Hi @rnagpal, I am out of office till next Tuesday. I had a look @ ur code. Can you try one thing ,change created date property type to datetimeoffset,also did you try running the code locally? When I saved the data to docdb from console app, I had no issue, but observed the UTC conversion once hosted in azure

[ArjunMenonUK]

Whenever I save to doc db from local I see no issue,but once its published to azure its all UTC.

[rnagpal]

@ArjunMenonUK we are aware of this issue when the DateTimeOffset type is used that it doesn't gets deserialized correctly when reading back, so as a workaround please use this date as string property and convert it into DateTimeOffset after reading the data from DocumentDB. I'll verify the local vs hosted on Azure difference you mentioned and report back. I assume that if you use that as string you are not seeing this issue locally as well as when hosted on Azure.

[ArjunMenonUK]

@rnagpal
Hi,
As of now we have kept date and offset separately and implemented it. String implementation will check and will update you . Anyway thanks for the update

[rnagpal]

@ArjunMenonUK Closing this issue. Let me know if you still see different values of the datetimeoffset property in local vs hosted on Azure when used as a string property in DocumentDB.

[jackbond]

Why was this issue closed? As it stands, DocumentDb has a MASSIVE BUG, let me repeat that...

A MASSIVE BUG

just for clarity

A MASSIVE BUG

in that your SDK is changing data values. Changing the property to a string is an EXTREMELY SHORT TERM WORKAROUND and a horrific one at that. I just downloaded Nuget 1.13.1 and the issue still exists. It is 100% unacceptable that this issue has not been resolved.

[ArjunMenonUK]

@jackbond i kept my datetime and offset separately as a work around. Felt more of a good method rather than keeping data as string :)

[jackbond]

@ArjunMenonUK Yah, their workarounds are terrible. I reported this bug months ago. To be clear, at this point SOMEONE OUGHT TO BE FIRED.

DateTimeOffset is the preferred class for storing dates in .NET. This bug should either be fixed, or the DocumentDb team should stand up and clearly state, WE DO NOT SUPPORT DATETIMEOFFSET.

For this bug to have been closed is simply INEXCUSIBLE.

[fabiomaulo]

@jackbond the solution is here
#292
;)