Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Feature request: DeserializationFeature.OPTIONAL_TIME_ZONE

Aberta
  • Algo errado?
#73 6 comentários 2 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
java
Domínio
backend

Direção de pesquisa

Comece pelo InstantDeserializer, que lida com valores Instant e ZonedDateTime, e inspecione DeserializationContext#getTimeZone. Determine como o DeserializationFeature.OPTIONAL_TIME_ZONE proposto deve afetar o parsing quando o sufixo estiver ausente, preservando os fusos horários explícitos. Considera-se concluído quando ambas as strings de exemplo forem desserializadas em valores equivalentes com o fuso horário de fallback configurado, e as entradas zoned existentes permanecerem inalteradas.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

new-feature

Hi,

In our project we need to accept ISO8601 date/time strings with optional time zones, where a specific time zone is to be assumed when the time zone is omitted from the string. In our specific case, the assumed time zone would be UTC, regardless of the system's current time zone.

So both of these strings would be deserialized to the same ZonedDateTime object:

  • 2018-05-22T10:29:56Z
  • 2018-05-22T10:29:56

Unfortunately, the latter cannot be deserialized to a ZonedDateTime (or an Instant for that matter), due to missing (and thus ambiguous) time zone information in the input string. Doing so would result in the following error:

java.lang.IllegalArgumentException: Cannot deserialize value of type `java.time.ZonedDateTime` from String "2018-05-22T10:29:56": Text '2018-05-22T10:29:56' could not be parsed at index 19

However, the specification that we are implementing in our project clearly states that the time zone of the string is supposed to be optional and if omitted, should be assumed to be UTC.

Currently, there is no way for us to tell Jackson to handle the input that way. And deserializing to LocalDateTime instead of ZonedDateTime would not be acceptable either, since that way, any explicitly specified time zone information would be ignored on deserialization.

What would really help here is a specific deserialization feature, named something like DeserializationFeature.OPTIONAL_TIME_ZONE. If enabled, the InstantDeserializer (used for deserializing to both Instant values and ZonedDateTime values) would then treat the time zone suffix (regardless of the notation, whether "Z", "+2:00" or whatever) as optional and assume the value of DeserializationContext#getTimeZone as the time zone when parsing temporal date/time input.

Perhaps there is an obvious existing way to solve this problem, but so far, I was unable to find it. If so, please let me know.

If not, could this proposed DeserializationFeature perhaps be implemented? Thank you kindly for considering this.

Linguagem predominante
Java
Estrelas
426
Forks
128
Merge médio
19min
PRs com merge (30d)
1

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de FasterXML/jackson-modules-java8

Todas as issues de FasterXML/jackson-modules-java8

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.