This datatype is an addition to the date datatype. However there is an important distinction between the two. The existing date datatype stores dates in millisecond resolution. The date_nanos data type stores dates in nanosecond resolution, which limits its range of dates from roughly 1970 to 2262, as dates are still stored as a long representing nanoseconds since the epoch.

Queries on nanoseconds 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.

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 including up to nine second fractionals or milliseconds-since-the-epoch (thus losing precision on the nano second part).

For instance:

PUT my_index?include_type_name=true
{
  "mappings": {
    "_doc": {
      "properties": {
        "date": {
          "type": "date_nanos" 
        }
      }
    }
  }
}

PUT my_index/_doc/1
{ "date": "2015-01-01" } 

PUT my_index/_doc/2
{ "date": "2015-01-01T12:10:30.123456789Z" } 

PUT my_index/_doc/3
{ "date": 1420070400 } 

GET my_index/_search
{
  "sort": { "date": "asc"} 
}

GET my_index/_search
{
  "script_fields" : {
    "my_field" : {
      "script" : {
        "lang" : "painless",
        "source" : "doc['date'].date.nanos" 
      }
    }
  }
}

GET my_index/_search
{
  "docvalue_fields" : [
    {
      "field" : "my_ip_field",
      "format": "strict_date_time" 
    }
  ]
}

You can also specify multiple date formats separated by ||. The same mapping parameters than with the date field can be used.