Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
IQueryable<> does not utilize custom CosmosSerializer when serializing datetimeoffset
See original GitHub issueDescribe the bug When serializing DateTimeOffset values, they are formatted like “2023-04-11T21:24:36.6331736+00:00” instead of like “2023-04-11T21:24:36.6331736Z”, even though I have configured a custom json serializer which formats DateTimeOffset’s properly for cosmos range indexing.
The result is that filters based on datetimeoffsets are not accurate
To Reproduce Steps to reproduce the behavior. If you can include code snippets or links to repositories containing a repro of the issue that can helps us in detecting the scenario it would speed up the resolution.
Expected behavior
ToQueryDefinition() should run values through the CosmosSerializer. This is also related to enums serialization issues (serializing as numbers).
Actual behavior DateTimeOffset formatted using some newtonsoft json serializer defaults
Environment summary SDK Version: 3.32.3 OS Version: Widows 10
Issue Analytics
- State:
- Created 5 months ago
- Comments:25 (25 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@ealsur valid concern re: backwards compatibility, but there needs to be some consideration for new implementers who, while implementing new applications using this SDK, may miss the subtle misbehavior between a string comparison and a date range comparison being done within Cosmos.
Perhaps this distinction should be added as a warning to the documentation, at the very least.
Many new .NET applications don’t mess around with DateTime objects anymore, since DateTimeOffset avoids any ambiguities around DateTimeKind, so this would be an immediate foot-gun built into the SDK that could be very difficult to notice. I would also not be surprised if many applications are simply wrong and implementors dont even realize their comparison is broken because it works 90% (or whatever percent) of the time.
@ealsur I feel the resolution of that issue has stalled, and this could be resolved without that fix - it could also be worked-around BY that fix, but wouldn’t change the default behavior, which is to serialize dates in a format Cosmos itself does not understand as a date.