java.time.Instant.toString() nanosecond bug
Roger Riggs
Roger.Riggs at Oracle.com
Wed Jan 18 18:24:10 UTC 2017
Hi Arne,
The arguments to Instant.ofEpochSecond[1] are seconds and nanoseconds.
So 123400 nanoseconds is more clearly written as 000_123_400.
Regards, Roger
[1]
http://download.java.net/java/jdk9/docs/api/java/time/Instant.html#ofEpochSecond-long-long-
On 1/17/2017 3:07 PM, Arne Ploese wrote:
> Hi,
>
> I'm runnig
>
> openjdk version "1.8.0_111"
> OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-3-b14)
> OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)
>
> and I encounter the following bug.
>
> TestCase:
>
> @Test
> public void testNanos() {
> DateTimeFormatter formatter =
> DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.nnnnnnX");
> Instant instant = Instant.ofEpochSecond(0, 123400);
> assertEquals(0, instant.getEpochSecond());
> assertEquals(123400, instant.getNano());
> assertEquals("1970-01-01T00:00:00.123400Z",
> formatter.format(ZonedDateTime.ofInstant(instant, ZoneId.of("Z"))));
> assertEquals("1970-01-01T00:00:00.123400Z",
> instant.toString());
> }
>
> The test fails on the last assertEquals with:
>
> org.junit.ComparisonFailure: expected:<1970-01-01T00:00:00.[]123400Z>
> but was:<1970-01-01T00:00:00.[000]123400Z>
>
> the nanos getting three leading zeros.
>
> Arne Plöse
More information about the core-libs-dev
mailing list