Search by timestamp doesn't work if milliseconds not specified

[maxiadlovskii]

Looks like for search by timestamp is mandatory to type full time in date value (with hours, minutes, seconds and milliseconds). For the user this behavior is not obvious and may mislead the user by displaying incorrect search result.

Expected Behavior

We should make search work if user didn't type millisecond, seconds or even time at all.
Or if there is any specific reason to use full date with time, we should add validation and inform user that its mandatory to type full date.

Current Behavior

If we type date without millisecond we wouldn't see any results and there is no message for the user that is need to type full date.

Possible Solution

Add as default values for milliseconds, seconds - 000, 00 respectively. Also if user didn't add time at all lets make it 00:00:00.000 by default (maybe 23:59 for upper boundary)

OR

Add validation and show message that user should type all values in time

Steps to Reproduce (for bugs)

1. Go to search page
2. type timestamp:["2022-01-01 00:00:00.000" TO "2022-12-01 00:00:00.000"] into search field.
3. You will see search result
4. 
5. type timestamp:["2022-01-01 00:00:00" TO "2022-12-01 00:00:00"] into search field (the same as before but without milliseconds)
6. There are no search results

Your Environment

• Graylog Version: development version for 4.3
• Java Version: 1.8
• Elasticsearch Version: 7.9.0
• MongoDB Version: 4.2
• Operating System: macOS 12.2.1 (21D62)
• Browser version: Google Chrome Version 98.0.4758.80 (Official Build) (arm64)

[vanduc1102]

Currently,

http://localhost:8080/api/search/validate

return OK for timestamp:["2022-01-01 00:00:00" TO "2022-12-01 00:00:00"]

I think it should return a WARNING like the below

[luk-kaminski]

We could also consider supporting multiple different type formats for dates, with notation like that:
"uuuu-MM-dd HH:mm:ss.SSS||uuuu-MM-dd HH:mm:ss||uuuu-MM-dd"
(see org.graylog2.indexer.ConstantsES7)

[kmerz]

I might be wrong, that strikes me as a feature request and not as an error. Am I right?

[luk-kaminski]

@kmerz - I have nothing against changing it from bug to feature request.

[janheise]

see #19551 for some already discussed approaches