Replace LocalDateTime with Instant

This issue concerns the support for the Logical Avro type timestamp_ms.

At present, the avrohugger maps the logical avro type timestamp_ms to the java.date.LocalDateTime Java class. We propose that, instead, the timestamp_ms logical type should be mapped to the java.time.Instant Java class.

The Avro logical type timestamp_ms is described in the specification as follows:

[…] represents an instant on the global timeline […] annotates an Avro long, where the long stores the number of milliseconds from the unix epoch, 1 January 1970 00:00:00.000 UTC.

This corresponds directly with the description of the java.time.Instant class, which says:

This class models a single instantaneous point on the time-line. This might be used to record event time-stamps in the application. […] The epoch-seconds are measured from the standard Java epoch of 1970-01-01T00:00:00Z

The LocalDateTime class is described in the documentation as serving a different purpose, more related to the human-readable descriptions of dates:

A date-time without a time-zone in the ISO-8601 calendar system. LocalDateTime is an immutable date-time object that represents a date-time, often viewed as year-month-day-hour-minute-second. This class does not store or represent a time-zone. […] It cannot represent an instant on the time-line without additional information such as an offset or time-zone.

Related Issues

Support for the logical timestamp_ms type was introduced in PR #87 by @raulraja, and a change to generate the converters is currently submitted in PR #88.

[julianpeeters]

Would you accept adding the needed marshalers to the tests for sbt-avrohugger

yep! nice solution

[diesalbla]

Freestyle needs avro4s compatibility, correct? It’s not just the scripted tests that need it?

freestyle-rpc uses avro4s for marshalling and unmarshalling from Avro. However, for those types not directly supported by avro4s, it defines its own instances, as you can see here

I’m fairly opposed to adding avro4s-specific code the generated classes, avrohugger should just generate plain old case classes for this use case IMO.

I understand, and agree, that avrohugger should be only about code generation, not marshalling-unmarshalling. Would you accept adding the needed marshalers to the tests for sbt-avrohugger?