Add method that parses dates without throwing exceptions

[danhermann]

To be used to improve the performance of the date processor when it encounters a lot of date patterns that do not match the supplied input.

Relates to #73918

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[elasticmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[danhermann]

@elasticmachine run elasticsearch-ci/bwc

[danhermann]

@elasticmachine update branch

[joegallo]

Is it expected that a success could result in a null TemporalAccessor? That is, is it acceptable to return Tuple.tuple(true, null)?

If not, what about Optional<TemporalAccessor>?

[danhermann]

Good idea. Done in 15622ec

[rjernst]

Could you explain how this differs from the existing parse method? The existing method doesn't catch exceptions, it looks almost identical to your new implementation. If the goal is to simply do away with any exceptions, then I think we should change the existing parse method to work like you have, but return null on no match. Having two methods will make it unclear which should be used.

[rjernst]

I do not think we should add another parse method. If this is more performant, then let's change the implementation of parse.

[danhermann]

Could you explain how this differs from the existing parse method? The existing method doesn't catch exceptions, it looks almost identical to your new implementation. If the goal is to simply do away with any exceptions, then I think we should change the existing parse method to work like you have, but return null on no match. Having two methods will make it unclear which should be used.

@rjernst, the existing method will throw an exception if none of the parsers complete successfully. I believe this was the intended behavior of the method given the explicit throw in the doParse method and its corresponding @throws entry in the method javadoc. This causes performance problems in a number of solutions use cases that make heavy use of the date processor in ingest pipelines since date parsing failures are not exceptional there.

This method is also used in many places in ES (mappings, cluster metadata, etc.) where its behavior is at least expected if not preferred since exceptions are explicitly caught and handled but null return values are not. I wouldn't presume to change all those other usages as a date parsing failure in those cases may very well be exceptional.

[rjernst]

I wouldn't presume to change all those other usages as a date parsing failure in those cases may very well be exceptional.
use cases that make heavy use of the date processor in ingest pipelines since date parsing failures are not exceptional there.

I don't think date parsing failure in other cases within Elasticsearch is any more or less exceptional. I would argue that even in ingest processors not having any patterns match is exceptional. Can you explain in what situation not matching any patterns is expected and normal?

I don't have a preference for either way, but I think we should stick with one type of error handling. Your new method is almost a copy of the existing parse method. These kinds of things can become tricky to keep in sync as changes are made over time. And like I mentioned in my previous comment, having 2 different ways to call a parser is confusing for callers, not knowing which is preferred.