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.
This commit is contained in:
Tal Levy 2017-05-30 09:42:26 -07:00 committed by GitHub
parent 5bcae914d9
commit 2a6e6866bd
2 changed files with 5 additions and 1 deletions

View File

@ -38,7 +38,7 @@ enum DateFormat {
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 {

View File

@ -50,6 +50,10 @@ public class DateFormatTests extends ESTestCase {
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));