Allow Instant to be serialized as epochSecond without the fraction part

I have an Instant field that represents an epoch timestamp in seconds.

    @JsonProperty("registered_at")
    @JsonFormat(shape = JsonFormat.Shape.NUMBER)
    private Instant registeredAt;

the mapper is configured this way

    .featuresToDisable(ADJUST_DATES_TO_CONTEXT_TIME_ZONE,
                       FAIL_ON_UNKNOWN_PROPERTIES,
                       WRITE_DATES_AS_TIMESTAMPS,
                       SORT_PROPERTIES_ALPHABETICALLY)

However when this gets serialized as

"registered_at" : 1420324047.000000000

By looking at the code there’s no way to serialize this value as epoch seconds using the standard mechanism.

InstantSerializerBase.serialize(T value, JsonGenerator generator, SerializerProvider provider)

        if (useTimestamp(provider)) {
            if (useNanoseconds(provider)) {
                generator.writeNumber(DecimalUtils.toBigDecimal(
                        getEpochSeconds.applyAsLong(value), getNanoseconds.applyAsInt(value)
                ));
                return;
            }
            generator.writeNumber(getEpochMillis.applyAsLong(value));
            return;
        }

The only option is to use :

    @JsonGetter("registered_at")
    public long getRegisteredAtEpoch() {
        return registeredAt.getEpochSecond();
    }

It could be nice if there could be way to tell jackson to avoid serializing the fraction part.

[jsnelgro]

Just wanted to post my solution here, since this was the first thread that came up in a web search and I didn’t see an explicit code snippet that solved my problem. I needed to serialize as epoch millisecond without globally configuring the ObjectMapper. This is what solved my use case (I’m working in Kotlin):

data class MyPojo(
  @JsonFormat(without = [JsonFormat.Feature.WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS])
  val timestamp: Instant
)

[nniesen]

I think it should be epoch millis for this change to be useful. Epoch millis makes the the timestamps portable with regard to both Java and JavaScript; which are the likely producers and consumers on both ends of the request.

Default serializer: Instant.toEpochMilli() Default deserializer: Instant.ofEpochMilli(long epochMilli)

I currently use this configuration:

jackson:
  serialization: # com.fasterxml.jackson.databind.SerializationFeature
    WRITE_DATES_AS_TIMESTAMPS: true # Instant.toEpochMillis()
    WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS: false
  deserialization: # com.fasterxml.jackson.databind.DeserializationFeature
    READ_DATE_TIMESTAMPS_AS_NANOSECONDS: false

This makes the timestamps easily transferrable between the platforms with consistent APIs.

Java:

long value = 1551461407999L
Instant deserialized = Instant.ofEpochMilli(value)
System.out.println(deserialized)
long serialized = deserialized.toEpochMilli()
System.out.println(serialized)
System.out.println(serialized == value)
System.out.println(Instant.ofEpochMilli(1551461407999L).toEpochMilli() == 1551461407999L)

Javascript:

var value = 1551461407999;
var deserialized = new Date(value);
console.log(deserialized.toISOString());
var serialized = deserialized.valueOf();
console.log(serialized);
console.log(serialized == value);
console.log(new Date(1551461407999).valueOf() == 1551461407999);

Moment.js:

var value = 1551461407999;
var deserialized = new moment(value);
console.log(deserialized.toISOString());
var serialized = deserialized.valueOf();
console.log(serialized);
console.log(serialized == value);
console.log(new moment(1551461407999).valueOf() == 1551461407999);

All 3 produce:

2019-03-01T17:30:07.999Z
1551461407999
true
true

If some needs/wants epoch seconds, they can use the Instant/Date APIs to truncate to seconds when creating the initial value.