Fix floating-point error when DateProcessor parses UNIX (#24947)

DateProcessor's DateFormat UNIX format parser resulted in
a floating point rounding error when parsing certain stringed
epoch times. Now Double.parseDouble is used, preserving the
intented input.

Author: talevy

modules/ingest-common/src/main/java/org/elasticsearch/ingest/common/DateFormat.java

@@ -38,7 +38,7 @@ Function<String, DateTime> getFunction(String format, DateTimeZone timezone, Loc
     Unix {
         @Override
         Function<String, DateTime> getFunction(String format, DateTimeZone timezone, Locale locale) {
-            return (date) -> new DateTime((long)(Float.parseFloat(date) * 1000), timezone);
+            return (date) -> new DateTime((long)(Double.parseDouble(date) * 1000), timezone);
         }
     },
     UnixMs {

modules/ingest-common/src/test/java/org/elasticsearch/ingest/common/DateFormatTests.java

@@ -50,6 +50,10 @@ public void testParseUnix() {
         assertThat(DateFormat.Unix.getFunction(null, DateTimeZone.UTC, null).apply("1000.5").getMillis(), equalTo(1000500L));
     }
 
+    public void testParseUnixWithMsPrecision() {
+        assertThat(DateFormat.Unix.getFunction(null, DateTimeZone.UTC, null).apply("1495718015").getMillis(), equalTo(1495718015000L));
+    }
+
     public void testParseISO8601() {
         assertThat(DateFormat.Iso8601.getFunction(null, DateTimeZone.UTC, null).apply("2001-01-01T00:00:00-0800").getMillis(),
                 equalTo(978336000000L));