Uploaded image for project: 'Apache Avro'
  1. Apache Avro
  2. AVRO-2360

Java 8 timestamp-millis / timestamp-micros type inconsistency



    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.9.0
    • Fix Version/s: 1.9.0
    • Component/s: java
    • Labels:
    • Environment:

      JDK 11.0.2 on Linux

    • Hadoop Flags:
      Incompatible change


      I am trying the new JSR 310 date/time types with a snapshot of 1.9.0.

      I see what seems to be an inconsistency. If I generate my code with a logical type of "timestamp-millis", then the code is generated with `Instant`, as expected. However, on JDK11 on Linux, if I do `Instant.now()` the Instant value created contains microseconds. When setting this Instant on an instance of the generated Avro SpecificRecord, I am unable to round-trip the data:

      Before serialization to bytes:

      System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665308Z

      After serializing to bytes, and then back into a specific record the microseconds are now truncated:

      System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665Z

      I believe the compiler should generate a class that truncates the microseconds at `setter` time for "timestamp-millis", so that the value before serialization, and after deserialization, are the same. This can be done with a call to the method `truncatedTo(ChronoUnit.MILLIS)`.

      Another, possibly related, oddity is that the "timestamp-micros" type generates a class with `long` as the type of the field. Since Instant can support both milli and micro-second precision, I don't see the reason for this behavior.

      Followup on AVRO-2079.


          Issue Links



              • Assignee:
                dkulp Daniel Kulp
                rocketraman Raman Gupta
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: