New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Datetime fields - ISO vs non-ISO - How does the behaviour of Cosmos DB change? #52598
Comments
I am unable to edit the title. I hit the Save button too quickly. Please, could the moderator update the title Thank you |
@sdg002 Thank you for the inquiry, and just to clarify your question you indicated the following:
The second item should read SomeDate, as you have detailed in the third list item. I was going to fix this but didn't want do so without clarifying. As for your specific question, if you look at the Storing DateTimes section of the document it states the following:
When you query within Cosmos DB only, it is treated as the same unless you attempted to filter on hours, minutes, or seconds. If you were to export the data to ANSI compliant SQL database and attempted to load those values into a DateTime column, the SomeDate value may not load correctly. Another instance is if you were to load this record into PowerBI, the SomeDate value may not be interpreted correctly and covert from UTC to a localized date/time value. I believe this should answer your question. Please let me know if this does not answer your question or you need more information. |
Thanks for the quick response. Could you explain with an example -
Could you explain with an example what feature of Cosmos DB makes it possible to accomplish this scenario ? |
@sdg002 I took your example record to make 4 records, each with unique Date values per record (not per property) and I am able to filter on a specific date with the following:
|
If I run the following query on the Example_Records.txt dataset:
I get the following record:
|
If I run the same query but with Less Than + Equals, I get the other three records minus the 4th dated in December:
|
@sdg002 We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion. |
@Mike-Ubezzi-MSFT The original intent of my question was to find out whether the engine of Cosmos DB internally handles ISO formatted strings in a special way and not just as another string field. Inspired by your sample, I extended your JSON by adding a new field
When I run the following queries and
I get identical results
On the surface, I see no difference between an ISO date and the date string yyyy/MM/dd. In bothe cases Cosmos carried out a lexical string comparison. ISO has no part to play here. I hope I was able to put my points clearly.
thanks for your patience. |
Hi @sdg002, your analysis above is correct! The reason we recommend using the ISO 8601 format is because this is the format that GetCurrentDateTime uses in Cosmos DB: https://docs.microsoft.com/en-us/azure/cosmos-db/sql-query-getcurrentdatetime If you wanted to use a different date format, that would be fine. The field is indexed in the same way (a string) regardless of the date format you choose. |
Consider the following JSON document :
The fields OrderDate and ShipDate follow ISO format.
But the field SomeDate does not follow ISO format.
Does Cosmos DB index the fields SomeDate differently from ShipDate and OrderDate?
How does Cosmos DB differ when it comes to range querying in the following scenarios?
ShipDate
using a SQL clause likeShipDate > "2014-09-30T23:14:25Z"
SomeDate
using a SQL clause likeSomeDate > 2014-09-30T00:00:00
It looks to me that storing date time fields as ISO strings is more driven by convention.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: