Date datatypeedit
JSON doesn’t have a date datatype, so dates in Elasticsearch can either be:
-
strings containing formatted dates, e.g.
"2015-01-01"
or"2015/01/01 12:10:30"
. - a long number representing milliseconds-since-the-epoch.
- an integer representing seconds-since-the-epoch.
Internally, dates are converted to UTC (if the time-zone is specified) and stored as a long number representing milliseconds-since-the-epoch.
Queries on dates are internally converted to range queries on this long representation, and the result of aggregations and stored fields is converted back to a string depending on the date format that is associated with the field.
Dates will always be rendered as strings, even if they were initially supplied as a long in the JSON document.
Date formats can be customised, but if no format
is specified then it uses
the default:
"strict_date_optional_time||epoch_millis"
This means that it will accept dates with optional timestamps, which conform
to the formats supported by strict_date_optional_time
or milliseconds-since-the-epoch.
For instance:
PUT my_index { "mappings": { "properties": { "date": { "type": "date" } } } } PUT my_index/_doc/1 { "date": "2015-01-01" } PUT my_index/_doc/2 { "date": "2015-01-01T12:10:30Z" } PUT my_index/_doc/3 { "date": 1420070400001 } GET my_index/_search { "sort": { "date": "asc"} }
The |
|
This document uses a plain date. |
|
This document includes a time. |
|
This document uses milliseconds-since-the-epoch. |
|
Note that the |
Multiple date formatsedit
Multiple formats can be specified by separating them with ||
as a separator.
Each format will be tried in turn until a matching format is found. The first
format will be used to convert the milliseconds-since-the-epoch value back
into a string.
PUT my_index { "mappings": { "properties": { "date": { "type": "date", "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis" } } } }
Parameters for date
fieldsedit
The following parameters are accepted by date
fields:
Mapping field-level query time boosting. Accepts a floating point number, defaults
to |
|
Should the field be stored on disk in a column-stride fashion, so that it
can later be used for sorting, aggregations, or scripting? Accepts |
|
The date format(s) that can be parsed. Defaults to
|
|
|
The locale to use when parsing dates since months do not have the same names
and/or abbreviations in all languages. The default is the
|
If |
|
Should the field be searchable? Accepts |
|
Accepts a date value in one of the configured |
|
Whether the field value should be stored and retrievable separately from
the |
|
Metadata about the field. |