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