jsun-m
(Jsun M)
April 14, 2023, 9:54pm
1
Query:
return {
"sort": [
{
"time": "desc"
},
],
"_source": ["@timestamp", "message", "time"],
"runtime_mappings": {
"date_has_nanos": {
"type": "boolean",
"script": "emit(doc['time'].value.nano != 0)"
}
},
"fields": [
{
"field": "time",
"format": "strict_date_optional_time_nanos"
},
{
"field": "date_has_nanos"
}
]
}
Expectation per entry:
"_score": null,
"_source": {
"@timestamp": "2023-04-14T20:33:36.831027500Z",
"message": "MESSAGE"
},
"fields": {
"@timestamp": [
"2023-04-14T20:33:36.831027500Z"
],
"date_has_nanos": [
true
]
},
"sort": [
1681504416831027500
]
Actual entry:
"_score": null,
"_source": {
"@timestamp": "2023-04-14T20:33:36.831027500Z",
"message": "MESSAGE"
},
"fields": {
"@timestamp": [
"2023-04-14T20:33:36.831Z"
],
"date_has_nanos": [
true
]
},
"sort": [
1681504416831
]
I'm getting an issue where the @timestamps loses precision when it is formatted by strict_date_optional_time_nanos
which leads the precision to be dumb down to milliseconds
dadoonet
(David Pilato)
April 17, 2023, 4:00pm
3
I'm wondering if you are hitting this:
opened 02:24PM - 08 Mar 21 UTC
>bug
:Search/Search
Team:Search
v7.9.0
We allow folks to specify dates like:
```
"d": 6123.123
```
Which you shou… ld read as `6123123000` nanoseconds since epoch. There are a lot of layers, but when we see this format we pretty much shift the decimal point six places to the right and parse the whole thing as nanoseconds. Then we use the standard java time utilities to convert that nanosecond precision instant into whatever the date's native format is. This all works fine on parsing.
But in a few places we let jackson deserialize the `_source` without type hints. When it sees a number like `6123.123` it automatically converts it to a double precision floating point value. This will lose precision for big dates. With `date` its *mostly* ok because double's maximum precise value is 9,007,199,254,740,992 which is something like the year 287396. If I live so long I'll be glad to fix the bugs. I say *mostly* here because there are some issues with rounding so we might end up being off by a millisecond. Sadly, with `date_nanos` we lose precision on any date after 6am, April 15th, 1970 UTC.
So, you rightly ask, when do we let jackson deserialize the `_source`? Well, when scripts access `_source` via `params._source`. And when we perform an `_update` action. And in the `fields` API. And maybe other places I haven't found yet.
Note: This describes the state we'll be in if we merge #70040.
jsun-m
(Jsun M)
April 17, 2023, 5:06pm
4
I'm looking to try this epoch_seconds into my query but it also mentions that putting date in _source
is not a good idea and instead put it as a field. Is there a way to convert this whenever i insert a log into Elasticsearch or update fluent bit to insert a date field automatically?
jsun-m
(Jsun M)
April 19, 2023, 4:27pm
5
after some modifications I am able to get my sort to have the value as nanoseconds but it still doesnt convert correctly
it shows it as 1681504416831000000 which totally excludes precision from 2023-04-14T20:33:36.831Z
jughosta
(Julia Rechkunova)
May 8, 2023, 12:04pm
6
Hi @jsun-m ,
Could you please try adding numeric_type
parameter as it's mentioned in the docs Paginate search results | Elasticsearch Guide [8.7] | Elastic
Example:
"sort": [
{
"@timestamp": {
"order": "asc",
"format": "strict_date_optional_time_nanos",
"numeric_type" : "date_nanos"
}
}
]
system
(system)
Closed
June 5, 2023, 12:05pm
7
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.