You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The setting mapping.date.round_ceil affects how date ranges are parsed, but only on the upper end of the range, and when the end is inclusive. It causes a slightly different date parsing function to be used, which will first try to parse as a date, and then try as a timestamp if the year is very large. If we want to support this timestamp fallback, it should happen for all date parsing, regardless of which end of the range it came from, or whether the end is inclusive.
Also, the setting index.mapping.date.parse_upper_inclusive appears to be from before 1.0, and is no longer documented. This setting is currently parsed and the value used as the default for mapping.date.round_ceil. Both of these settings should be removed to ensure date ranges are parsed symmetrically.
The text was updated successfully, but these errors were encountered:
The setting `mapping.date.round_ceil` (and the undocumented setting
`index.mapping.date.parse_upper_inclusive`) affect how date ranges using
`lte` are parsed. In elastic#8556 the semantics of date rounding were
solidified, eliminating the need to have different parsing functions
whether the date is inclusive or exclusive.
This change removes these legacy settings and improves the tests
for the date math parser (now at 100% coverage!). It also removes the
unnecessary function `DateMathParser.parseTimeZone` for which
the existing `DateTimeZone.forID` handles all use cases.
Any user previously using these settings can refer to the changed
semantics and change their query accordingly. This is a breaking change
because even dates without datemath previously used the different
parsing functions depending on context.
closeselastic#8598closeselastic#8889
The setting
mapping.date.round_ceil
affects how date ranges are parsed, but only on the upper end of the range, and when the end is inclusive. It causes a slightly different date parsing function to be used, which will first try to parse as a date, and then try as a timestamp if the year is very large. If we want to support this timestamp fallback, it should happen for all date parsing, regardless of which end of the range it came from, or whether the end is inclusive.Also, the setting
index.mapping.date.parse_upper_inclusive
appears to be from before 1.0, and is no longer documented. This setting is currently parsed and the value used as the default formapping.date.round_ceil
. Both of these settings should be removed to ensure date ranges are parsed symmetrically.The text was updated successfully, but these errors were encountered: