You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
OffsetTimeSerializer not writing seconds for time object like 15:30:00Z (where seconds is 00) #299
When having a OffsetTime field with e.g. 15:00:00Z and serializing this with Jackson it outputs: 15:00Z and thus the seconds are lost.
Note I have the time module registered via JavaTimeModule().
Although one could argue that the seconds are not needed this gives some problems when validating outputted data against JSON schema.
when using the JSON schema format time then the seconds are expected, see https://json-schema.org/understanding-json-schema/reference/string#dates-and-times
without the seconds the JSON schema validator fails with: The value must be a valid time.
(note I'm using Justify for schema validation)
private final void _serializeAsArrayContents(OffsetTime value, JsonGenerator g,
SerializerProvider provider)
throws JacksonException
{
g.writeNumber(value.getHour());
g.writeNumber(value.getMinute());
final int secs = value.getSecond();
final int nanos = value.getNano();
if ((secs > 0) || (nanos > 0)) {
g.writeNumber(secs);
if (nanos > 0) {
if(useNanoseconds(provider)) {
g.writeNumber(nanos);
} else {
g.writeNumber(value.get(ChronoField.MILLI_OF_SECOND));
}
}
}
g.writeString(value.getOffset().toString());
}
Is it possible to override this behaviour?
Currently I think my only option is create a custom Serializer?
If not possible to override this behaviour would it be at least possible to change this _serializeAsArrayContents method from private to protected so one could simply extend this class and override this method?
changed the title [-]OffsetTimeSerializer not writing seconds for time like 15:30:00Z (where seconds is 00)[/-][+]OffsetTimeSerializer not writing seconds for time object like 15:30:00Z (where seconds is 00)[/+]on Jan 19, 2024
Hmm, JSR310FormattedSerializerBase (which the OffsetTimeSerializer extends) is also package protected. So just making that method protected would not help unfortunately.
I would not be against relaxing visibility rules where necessary, fwtw (PRs welcome). But sounds like that might not work.
Aside from that, yes, it seems like we could use more configurability. In many cases we could use one of properties of @JsonFormat (which allows use both via annotation itself, and with "ConfigOverrides" which allows specifying JsonFormat.Value for given type) -- but I don't think that'd have suitable option here.
Which would leave 2 further options:
Adding direct configurability to OffsetTimeSerializer -- probably simple setter method (instead of passing in constructor). Not super elegant but would work
Addition of new JavaTimeFeature option (this was added in Jackson 2.16). One challenge is that ideally these settings should be relevant for more than one Date/Time value type. If similar "always include seconds" (... and how about Nanos?) needs exist for other value types, I think this would be the way to go.
I can't guarantee having time to work on this, but I always try to find time to help others if you wanted to try a PR.
Wrt versioning, new functionality should go in 2.17 branch, but I could allow "dark launch" for safe enough features for 2.16 (2.16.2) since 2.17.0 won't be released for months.
But reading through issue, I wonder if this is what is wanted: I think references are for Json STRING serialization -- and if so, this method is NOT used. Rather, custom DateTimeFormatter would be needed.
Note: added test-needed to verify what is needed; description is ambiguous wrt actual serialization (talks about JSON Array serialization handling, but title has JSON String -- guessing it's really latter).
Activity
[-]OffsetTimeSerializer not writing seconds for time like 15:30:00Z (where seconds is 00)[/-][+]OffsetTimeSerializer not writing seconds for time object like 15:30:00Z (where seconds is 00)[/+]marceloverdijk commentedon Jan 19, 2024
Hmm,
JSR310FormattedSerializerBase(which theOffsetTimeSerializerextends) is also package protected. So just making that methodprotectedwould not help unfortunately.cowtowncoder commentedon Jan 20, 2024
I would not be against relaxing visibility rules where necessary, fwtw (PRs welcome). But sounds like that might not work.
Aside from that, yes, it seems like we could use more configurability. In many cases we could use one of properties of
@JsonFormat(which allows use both via annotation itself, and with "ConfigOverrides" which allows specifyingJsonFormat.Valuefor given type) -- but I don't think that'd have suitable option here.Which would leave 2 further options:
OffsetTimeSerializer-- probably simple setter method (instead of passing in constructor). Not super elegant but would workJavaTimeFeatureoption (this was added in Jackson 2.16). One challenge is that ideally these settings should be relevant for more than one Date/Time value type. If similar "always include seconds" (... and how about Nanos?) needs exist for other value types, I think this would be the way to go.I can't guarantee having time to work on this, but I always try to find time to help others if you wanted to try a PR.
Wrt versioning, new functionality should go in 2.17 branch, but I could allow "dark launch" for safe enough features for 2.16 (2.16.2) since 2.17.0 won't be released for months.
Change `OffsetTimeSerializer._serializeAsArrayContents()` to `protect…
cowtowncoder commentedon Nov 18, 2025
Changed method visibility (and removed
final) so it's now overridable:But reading through issue, I wonder if this is what is wanted: I think references are for Json STRING serialization -- and if so, this method is NOT used. Rather, custom
DateTimeFormatterwould be needed.At any rate, change made.
cowtowncoder commentedon Nov 18, 2025
Note: added
test-neededto verify what is needed; description is ambiguous wrt actual serialization (talks about JSON Array serialization handling, but title has JSON String -- guessing it's really latter).