New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mapping: Improve date handling #10971
Comments
This commit changes the date handling. First and foremost Elasticsearch does not try to convert every date to a unix timestamp first and then uses the configured date. This now allows for dates like `2015121212` to be parsed correctly. Instead it is now explicit by adding a `epoch_second` and `epoch_millis` date format. This also means, that the default date format now is `epoch_millis||dateOptionalTime` to remain backwards compatible. Closes elastic#5328 Relates elastic#10971
This commit changes the date handling. First and foremost Elasticsearch does not try to convert every date to a unix timestamp first and then uses the configured date. This now allows for dates like `2015121212` to be parsed correctly. Instead it is now explicit by adding a `epoch_second` and `epoch_millis` date format. This also means, that the default date format now is `epoch_millis||dateOptionalTime` to remain backwards compatible. Closes elastic#5328 Relates elastic#10971
Does this affect range queries as well? I just tried using Kibana 4 with ES 2.0 and I got the following error:
If I add |
@simianhacker yes it does. When creating a range query in kibana, do you always use a unix timestamp or just in this example? I think it makes sense to build this BWC compatible.. will check it out |
We always use a Unix timestamp because it has historically been accepted regardless of format. While we know the format from the mapping, there are differences between our date formatting lib and Joda. |
I like this plan, at query time, I am leaning towards supporting the special format of |
In order to be backwards compatible, indices created before 2.x must support indexing of a unix timestamp and its configured date format. Indices created with 2.x must configure the `epoch_millis` date formatter in order to support this. Relates elastic#10971
Also see #14565 - Java8 prepends a plus sign to years > 9999 |
Is there anything that remains to be done before closing this issue? Most items look implemented, except the |
@jpountz the reason for the special format was because dates are no longer required to understand epoch ms, so eg kibana (which always uses epoch ms) wouldn't work with a custom mapped field that doesn't specify |
The current date mapping code treats unix timestamps differently from other date formats. We should unify this, even though this requires changing our defaults and requires the user to explicitely configure the unix timestamp usecase.
Today we parse dates as follows:
Mapped fields with a format (defaults to dateOptionalTime)
Dynamic date detection
:
,-
, or/
dateOptionalTime || yyyy/MM/dd HH:mm:ss || yyyy/MM/dd
)date
, elsestring
There are a few issues which can surprise users:
"1/1/1"
is detected as a date, and"1"
would be interpreted as0001-01-01 00:00:00
_timestamp
), a date in thequery_string
query is always a string, and even in the JSON body some languages can render a number as a string and vice versa2015.01.01
(german) or20150101T000000
(iso8601) can never be detected dynamicallyProposals
Make date parsing as unambiguous as possible. Where there is ambiguity, it is because the user chose ambiguous options (which we can warn about in the docs).
For indices created in 2.0:
epoch_ms
andepoch_seconds
Added epoch date formats to configure parsing of unix dates #11453numeric_resolution
(not needed with above)For mapped
date
field:strictDateOptionalTime || epoch_ms
For dynamic date detection:
epoch_ms
andepoch_seconds
epoch_ms
?)For indices created before 2.0:
We need to keep bwc on older indices, so we follow the same rules as specified at the beginning of this comment
Query time
Typically users will always use the same format at index time - they don't mix epoch timestamps with formatted dates, which is why we should only parse the specified formats.
However, at query time it is quite possible that (eg) Kibana may query with epoch timestamps, even though the date field only accepts a formatted date. Today, in the
range
query we accept aformat
parameter which is used to parse dates at query time.There are two options to deal with this situation:
format
parameter to theterm
,terms
,query_string
, andsimple_query_string
queries, and to therange
aggregationepoch_ms:123456789
The text was updated successfully, but these errors were encountered: