Inconsistency in Range-Operator and DateTime

[Kilmatead]

Example:

Code: Select all

dm:2026-02-10T00:00:00..2026-02-10T23:59:59

...results in the expected range of any time for the full day.

However, if you use the '/' date separator (instead of '-')

Code: Select all

dm:2026/02/10T00:00:00..2026/02/10T23:59:59

...results in no matches at all.

Including milliseconds (.sss) allows either date separator to work as it explicitly isolates the '..' range-operator.

For the sake of argument, I am aware that there are many ways of "working around" this issue (removing the times entirely or removing the :ss suffix, or adding .sss, etc), however, the original discrepancy of the two different date separators vs the range-operator (without milliseconds) remains.

Bug, or just a shout-out against living pedantically?

[NotNull]

This is the standardized ISO-8601 format.

See Date Syntax for more options

[Kilmatead]

Yes, I know - I even read ISO-8601, and it makes no distinction between a date rendered as yyyy/mm/dd or yyyy-mm-dd (solidus vs. hyphen), whereas ES apparently does when using the range-operator with a time suffix.

My question is whether that's intentional or not (I doubt it is). The main point being that parsing the range-operator doesn't distinguish well between a missing (optional?) '.sss' or just interpreting the literal '..' operator itself.

[void]

The main point being that parsing the range-operator doesn't distinguish well between a missing (optional?) '.sss' or just interpreting the literal '..' operator itself.

This is the issue.
Thank you for bringing this issue to my attention.
It will be fixed in the next alpha update.

[void]

Everything 1.5.0.1405a fixes an issue with eating . in a date/time range.