Floating-point value accepted for a date field during indexing, but fails later on update/re-index

[capnbab]

Elasticsearch version (bin/elasticsearch --version):
7.9.2

Plugins installed: []

JVM version (java -version):
openjdk version "15" 2020-09-15
OpenJDK Runtime Environment AdoptOpenJDK (build 15+36)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15+36, mixed mode, sharing)

OS version (uname -a if on a Unix-like system):
Linux 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Description of the problem including expected versus actual behavior:
Floating-point values are accepted into a date field during initial document insert, but cause later update/re-index operations to fail.

I would expect that since the value is not a properly formatted date string, a long, or an integer, that the insert should have thrown the bad format error.

Steps to reproduce:

# 1. delete the index
curl -XDELETE localhost:9200/test

# 2. create index, include a date property
curl -X PUT "localhost:9200/test?pretty" -H 'Content-Type: application/json' -d'{
  "mappings": {
    "properties": {
      "some_date": { "type": "date" }
    }
  }
}'

# 3. insert a document, using a float for the date. this should error for bad date format, but actually succeeds.
curl -X PUT "localhost:9200/test/_doc/1?pretty" -H 'Content-Type: application/json' -d'{
  "some_date" : 1616619193352.3
}'

# 4. try to update the document (e.g. add a new field). returns date_time_parse_exception.
curl -X POST "localhost:9200/test/_update/1?pretty" -H 'Content-Type: application/json' -d'{
  "doc": {
    "name": "new_name"
  }
}'

[elasticmachine]

Pinging @elastic/es-core-features (Team:Core/Features)

[elasticmachine]

Pinging @elastic/es-search (Team:Search)

[cbuescher]

So far I can see that on update the "_source" we need to re-parse contains the original date value in scientific notation ({"some_date":1.6166191933523E12,"name":"new_name"}), which is probably an effect of either the initial json parsing of the original document or an effect of rendering it when we retrieve it again for the update. I don't know if it is possible to avoid this conversion or if as an alternative we could make the date parser accept scientific notation, since it already seems to be able to coerce the numeric part from the original input. Maybe @pgomulka has some ideas around this?

[pgomulka]

The date is correct it means 1616619193352 millis and 3 nanoseconds
The exception on update looks like a bug.
Related to #70040 - a fix by @nik9000 - but that PR did not fix this for the update scenario.
a workaround is to wrap the date in quotes. "some_date" : "1616619193352.3"
I will try to work on a fix

---

a similar problem still ongoing #70085
also related to #69382

this can also likely be fixed by - #46531

[nik9000]

I was sort of hoping that we could avoid ever doing anything on the "map of maps" side. But a bug like this sort of forces us to do something there. I'm not sure what, frankly.

[elasticsearchmachine]

Pinging @elastic/es-search-foundations (Team:Search Foundations)

[hitesh-55]

Do we have any update on this or any work around ?