title: Elasticsearch alpine docker with jdk8 java.time.Instant causes epochSecond error
body: <p>I have recently tried 2.4.6-alpine with a change from <code>java.util.Date</code> to JDK 8 <code>java.time.Instant</code></p>
  
  <p>The Log document is using spring-boot auto injection.</p>
  
  <pre><code>import java.time.Instant;
  
  @Document(indexName = "log")
  public class Log {
  
      @Id
      private String id;
  
      @Field(type = FieldType.Date, store = true)
      private Instant timestamp = null;
  ...
  </code></pre>
  
  <p>The previous Log document looked like this.</p>
  
  <pre><code>import java.util.Date;
  @Document(indexName = "log")
  public class Log {
  
      @Id
      private String id;
  
      @Field(type = FieldType.Date, store = true)
      private Date timestamp = null;
  </code></pre>
  
  <p>On ES 2.4.6-alpine with <code>java.util.Date</code> and ES 2.4.6 with <code>java.time.Instant</code>, I don't have any problems.  </p>
  
  <p>However, on ES 2.4.6-alpine with <code>java.time.Instant</code>, I see the following error.
  It appears to be an issue with alpine linux and java.time formatting.</p>
  
  <pre><code>   SEVERE: Servlet.service() for servlet [dispatcherServlet] in context with path [/v1] threw exception [Request processing failed; nested exception is MapperParsingException[failed to parse [timestamp]]; nested: IllegalArgumentException[unknown property [epochSecond]];] with root cause
   java.lang.IllegalArgumentException: unknown property [epochSecond]
        at org.elasticsearch.index.mapper.core.DateFieldMapper.innerParseCreateField(DateFieldMapper.java:520)
        at org.elasticsearch.index.mapper.core.NumberFieldMapper.parseCreateField(NumberFieldMapper.java:241)
        at org.elasticsearch.index.mapper.FieldMapper.parse(FieldMapper.java:321)
        at org.elasticsearch.index.mapper.DocumentParser.parseObjectOrField(DocumentParser.java:311)
        at org.elasticsearch.index.mapper.DocumentParser.parseObject(DocumentParser.java:328)
        at org.elasticsearch.index.mapper.DocumentParser.parseObject(DocumentParser.java:254)
        at org.elasticsearch.index.mapper.DocumentParser.parseDocument(DocumentParser.java:124)
        at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:309)
        at org.elasticsearch.index.shard.IndexShard.prepareCreate(IndexShard.java:533)
        at org.elasticsearch.index.shard.IndexShard.prepareCreateOnPrimary(IndexShard.java:510)
        at org.elasticsearch.action.index.TransportIndexAction.prepareIndexOperationOnPrimary(TransportIndexAction.java:214)
        at org.elasticsearch.action.index.TransportIndexAction.executeIndexRequestOnPrimary(TransportIndexAction.java:223)
        at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:157)
        at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:66)
        at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryPhase.doRun(TransportReplicationAction.java:657)
        at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
        at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryOperationTransportHandler.messageReceived(TransportReplicationAction.java:287)
        at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryOperationTransportHandler.messageReceived(TransportReplicationAction.java:279)
        at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:77)
        at org.elasticsearch.transport.TransportService$4.doRun(TransportService.java:378)
        at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
  </code></pre>
  
  <p>Any advice to use java.time.* with alpine elasticsearch?</p>
  
  <p>After <code>docker-compose up -d</code> command, when I do <code>curl -xGET localhost:9200/*</code>
  I see there is some initial data.  This data comes back even after <code>-XDELETE</code> and <code>docker-compose down</code> and <code>docker-compose up -d</code> commands.</p>
  
  <p>The initial data from the both the elasticsearch:2.4.6 and elasticsearch:2.4.6-alpine dockers is the same.</p>
  
  <pre><code>{
    "log":{
      "aliases":{},
      "mappings":{
        "log":{
          "properties":{
            "timestamp":{
              "type":"date",
              "store":true,
              "format":"strict_date_optional_time||epoch_millis"
             }
           }
         }
       },
       "settings":{
         "index":{
           "refresh_interval":"1s",
           "number_of_shards":"5",
           "creation_date":"1513716676662",
           "store":{
             "type":"fs"
           },
           "number_of_replicas":"1",
           "uuid":"qlj9xxxxxxxxxxxxxxoisA",
           "version":{
             "created":"2040699"
           }
         }
       },
       "warmers":{}
     }
   }
  </code></pre>
  
  <p>Ahh.  The initial data is populated during startup of the spring-boot service's auto-injection of the Log document class used in my Elasticsearch implementation.</p>
  
  <p>Found a nice reference to the date-time formats in the javadoc for org.springframework.data.elasticsearch.annotation.DateFormat class. SOO many time formats with names and none match my output:(</p>
  
  <p><a href="http://nocf-www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html" rel="nofollow noreferrer">http://nocf-www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html</a></p>