-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[ml] supporting date_nanos as timestamp for the input #49889
Comments
Pinging @elastic/ml-core (:ml) |
Using the ml APIs directly rather than kibana it is possible to create a run a job on data with a time field of type The error mentioned above comes from the UI, I've raised elastic/kibana#52921 in place of this. |
Re-opening. As it stands with |
It turns out this was only true if the extra precision was not used. In other words, a datafeed would work fine on the #51180 fixes the case of a fractional number of milliseconds since the epoch. (And note that the smallest possible ML |
Allows ML datafeeds to work with time fields that have the "date_nanos" type _and make use of the extra precision_. (Previously datafeeds only worked with time fields that were exact multiples of milliseconds. So datafeeds would work with "date_nanos" only if the extra precision over "date" was not used.) Relates #49889
Allows ML datafeeds to work with time fields that have the "date_nanos" type _and make use of the extra precision_. (Previously datafeeds only worked with time fields that were exact multiples of milliseconds. So datafeeds would work with "date_nanos" only if the extra precision over "date" was not used.) Relates #49889
I believe this is fixed in 7.7 and above by elastic/kibana#59017 |
At present, trying to use a field of datatype
date_nanos
will return error :Some indices may only use timestamps with precision requiring datatype date_nanos, these indices cannot be used for input for machine learning jobs (unless another field of datatype date is added)
Note this feature request is limited to the input - it not related to being able to process data in nano seconds or below current second bucket_span raised in 644
The text was updated successfully, but these errors were encountered: