-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Anchored DateMath no longer serializes time zone information for local DateTime #3899
Comments
Thanks for opening @jonyadamit. This is a bug that has crept in with the move to Utf8Json. Will open a fix shortly. In the meantime, the workaround would be to convert the |
This commit adds the time zone information for a DateTime within a DateMath type, when the DateTimeKind is Local or Utc. This behaviour aligns 7.x with 6.x. Introduce StringBuilderCache for caching a StringBuilder per thread. Use of this can be extended in a later commit. Fixes #3899
I've opened #3910 to address |
This commit adds the time zone information for a DateTime within a DateMath type, when the DateTimeKind is Local or Utc. This behaviour aligns 7.x with 6.x. Introduce StringBuilderCache for caching a StringBuilder per thread. Use of this can be extended in a later commit. Fixes #3899
This commit adds the time zone information for a DateTime within a DateMath type, when the DateTimeKind is Local or Utc. This behaviour aligns 7.x with 6.x. Introduce StringBuilderCache for caching a StringBuilder per thread. Use of this can be extended in a later commit. Fixes #3899
This commit adds the time zone information for a DateTime within a DateMath type, when the DateTimeKind is Local or Utc. This behaviour aligns 7.x with 6.x. Introduce StringBuilderCache for caching a StringBuilder per thread. Use of this can be extended in a later commit. Fixes #3899
This commit adds the time zone information for a DateTime within a DateMath type, when the DateTimeKind is Local or Utc. This behaviour aligns 7.x with 6.x. Introduce StringBuilderCache for caching a StringBuilder per thread. Use of this can be extended in a later commit. Fixes #3899
This is only a suggestion but wouldn't it be cleaner in the DateMath.ToMinThreeDecimalPlaces function to simply change the actual "yyyy-MM-ddTHH:mm:ss.FFFFFFF" format to "yyyy-MM-ddTHH:mm:ss.fffffffK" or we we really need to keep the string shorter, get the timezone string in a second call to .ToString(" K").Substring(1) and concatenate instead of reimplementing the TZ logic? |
NEST/Elasticsearch.Net version:
7.0.0
Elasticsearch version:
7.2.0
Description of the problem including expected versus actual behavior:
Given the query
Nest 6.8.0 generates the following query: (my local time is UTC + 3)
{"query":{"range":{"some_field":{"gte":"2019-07-01T17:16:18.1266967+03:00"}}}}
Nest 7.0.0 generates the following query:
{"query":{"range":{"some_field":{"gte":"2019-07-01T17:16:18.1266967"}}}}
As a workaround for now I guess I have to either manually convert dates to UTC or add the TimeZone property (either of which adds unnecessary complexity).
The text was updated successfully, but these errors were encountered: