Dangerous behaviour of timestring

According to docs the timestring finds pattern anywhere in the index name. Nowadays it is best practice for log management indexes to include beats version in index names. We also include our doc version in index name and use not only beats as agents. So index names can be:
- index-myversion-50-filebeat-6.3.0-2018.05
- index-myversion-10-customagent-12.5-2018.05

and easily become:
- index-myversion-10-customagent-2019.11-2018.05

As it is more and more favourite to do big number steps (or use year versioning) in app versions.

I propose to add config option to allow timestring position. In most cases the date will be the last part of index name so by default it could also be fixed to "DATE$" pattern.

I think it is a matter of time this behaviour will cause a big troubles.

Start with the timestring documentation and the existing behavior for matching dates in index names. Compare that behavior with the supplied versioned index examples; done means a configurable position prevents version numbers from being interpreted as dates and the expected behavior is documented.

Written by the indexing model from the issue text.