Problem with far future millisecond values for Date type in ES 2.x

[Omega359]

This used to work in 1.3.4 but currently in 2.3.1 this seems to have broken.

 curl -XPUT http://localhost:9200/test -d '{
  "mappings": {
    "my_type": {
      "properties": {
        "date": {
          "type": "date"
        }
      }
    }
  }
}'

curl -XPUT http://localhost:9200/test/my_type/2 -d '{"date" : 999999999999}'

{"index":"test","type":"my_type","id":"2","version":1,"_shards":{"total":1,"successful":1,"failed":0},"created":true}

curl -XPUT http://localhost:9200/test/my_type/3 -d '{"date" : 10000000000000}'
or for my exact data
curl -XPUT http://localhost:9200/test/my_type/3 -d '{"date" : 32603904000000}'
[2016-04-20 13:44:27,278][DEBUG][action.index ] [VeevaNetworkNode1] failed to execute [index {[test][my_type][3], source[{"date" : 32603904000000}]}] on [[test][4]]
MapperParsingException[failed to parse [date]]; nested: IllegalArgumentException[Invalid format: "32603904000000" is malformed at "3904000000"];

Looking at the code in org.elasticsearch.common.joda.Joda$EpochTimeParser/$EpochTimePrinter it looks that the 13 digit limit is hardcoded but for the life of me I can't figure out why it would be.

[rjernst]

It seems to me the entire block in the epoch time parser checking for "too long" values should just be removed? @spinscale I see this was part of your original change to separate out epoch parsing from normal date parsing, but since the date format parsing is tried in order, why does epoch parsing need to do anything except just parse a long?

[spinscale]

agreed, I dont see any immediate reason to not support dates lower than 1653 and higher than 2286. I guess I could not imagine a use-case for that, as regular dates would have been so much simpler, see the discussion in #11482

[spinscale]

closed by #18509