Formato de data Mapeando para JSON Jackson

Eu tenho um formato de data vindo da API como este:

"start_time": "2015-10-1 3:00 PM GMT+1:00"

Qual é o carimbo de data / hora AAAA-DD-MM HH: MM am / pm GMT. Estou mapeando esse valor para uma variável Date no POJO. Obviamente, está mostrando erro de conversão.

Eu gostaria de saber 2 coisas:

1. Qual é a formatação que preciso usar para realizar a conversão com Jackson? Data é um bom tipo de campo para isso?
2. Em geral, existe uma maneira de processar as variáveis ​​antes que elas sejam mapeadas para membros do objeto por Jackson? Algo como, alterar o formato, cálculos, etc.

Qual é a formatação que preciso usar para realizar a conversão com Jackson? Data é um bom tipo de campo para isso?

Dateé um tipo de campo fino para isso. Você pode tornar o JSON analisável com bastante facilidade usando ObjectMapper.setDateFormat:

DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm a z");
myObjectMapper.setDateFormat(df);

Em geral, existe uma maneira de processar as variáveis ​​antes que elas sejam mapeadas para membros do objeto por Jackson? Algo como, alterar o formato, cálculos, etc.

Sim. Você tem algumas opções, incluindo a implementação de um costume JsonDeserializer, por exemplo, extensão JsonDeserializer<Date>. Este é um bom começo.

Desde o Jackson v2.0, você pode usar a anotação @JsonFormat diretamente nos membros do Object;

@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd HH:mm a z")
private Date date;

Obviamente, existe uma maneira automatizada chamada serialização e desserialização e você pode defini-la com anotações específicas ( @JsonSerialize , @JsonDeserialize ), conforme mencionado pelo pb2q.

Você pode usar java.util.Date e java.util.Calendar ... e provavelmente o JodaTime também.

As anotações @JsonFormat não funcionaram para mim como eu queria ( ajustou o fuso horário para um valor diferente) durante a desserialização (a serialização funcionou perfeitamente):

@JsonFormat(locale = "hu", shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd HH:mm", timezone = "CET")

@JsonFormat(locale = "hu", shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd HH:mm", timezone = "Europe/Budapest")

Você precisa usar o serializador personalizado e o desserializador personalizado em vez da anotação @JsonFormat, se desejar um resultado previsto. Encontrei um bom tutorial e solução aqui http://www.baeldung.com/jackson-serialize-dates

Existem exemplos para os campos Data , mas eu precisava para os campos Calendário , então aqui está minha implementação :

A classe do serializador :

public class CustomCalendarSerializer extends JsonSerializer<Calendar> {

    public static final SimpleDateFormat FORMATTER = new SimpleDateFormat("yyyy-MM-dd HH:mm");
    public static final Locale LOCALE_HUNGARIAN = new Locale("hu", "HU");
    public static final TimeZone LOCAL_TIME_ZONE = TimeZone.getTimeZone("Europe/Budapest");

    @Override
    public void serialize(Calendar value, JsonGenerator gen, SerializerProvider arg2)
            throws IOException, JsonProcessingException {
        if (value == null) {
            gen.writeNull();
        } else {
            gen.writeString(FORMATTER.format(value.getTime()));
        }
    }
}

A classe desserializador :

public class CustomCalendarDeserializer extends JsonDeserializer<Calendar> {

    @Override
    public Calendar deserialize(JsonParser jsonparser, DeserializationContext context)
            throws IOException, JsonProcessingException {
        String dateAsString = jsonparser.getText();
        try {
            Date date = CustomCalendarSerializer.FORMATTER.parse(dateAsString);
            Calendar calendar = Calendar.getInstance(
                CustomCalendarSerializer.LOCAL_TIME_ZONE, 
                CustomCalendarSerializer.LOCALE_HUNGARIAN
            );
            calendar.setTime(date);
            return calendar;
        } catch (ParseException e) {
            throw new RuntimeException(e);
        }
    }
}

e o uso das classes acima:

public class CalendarEntry {

    @JsonSerialize(using = CustomCalendarSerializer.class)
    @JsonDeserialize(using = CustomCalendarDeserializer.class)
    private Calendar calendar;

    // ... additional things ...
}

Usando essa implementação, a execução do processo de serialização e desserialização resulta consecutivamente no valor de origem.

Somente usando a anotação @JsonFormat, a desserialização dá um resultado diferente , acho que, devido à configuração padrão do fuso horário interno da biblioteca, o que você não pode alterar com os parâmetros de anotação (essa também foi minha experiência com as versões 2.5.3 e 2.6.3 da biblioteca Jackson).

Apenas um exemplo completo para o aplicativo de inicialização com RFC3339formato de data e hora

package bj.demo;

import com.fasterxml.jackson.databind.ObjectMapper;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.event.ApplicationReadyEvent;
import org.springframework.context.ApplicationListener;

import java.text.SimpleDateFormat;

/**
 * Created by BaiJiFeiLong@gmail.com at 2018/5/4 10:22
 */
@SpringBootApplication
public class BarApp implements ApplicationListener<ApplicationReadyEvent> {

    public static void main(String[] args) {
        SpringApplication.run(BarApp.class, args);
    }

    @Autowired
    private ObjectMapper objectMapper;

    @Override
    public void onApplicationEvent(ApplicationReadyEvent applicationReadyEvent) {
        objectMapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssXXX"));
    }
}

Para adicionar caracteres como T e Z na sua data

@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd'T'HH:mm:ss'Z'")
private Date currentTime;

resultado

{
    "currentTime": "2019-12-11T11:40:49Z"
}

Trabalhando para mim. SpringBoot.

 import com.alibaba.fastjson.annotation.JSONField;

 @JSONField(format = "yyyy-MM-dd HH:mm:ss")  
 private Date createTime;

resultado:

{ 
   "createTime": "2019-06-14 13:07:21"
}

Com base na resposta muito útil de @ miklov-kriven, espero que esses dois pontos adicionais de consideração sejam úteis para alguém:

(1) Acho uma boa ideia incluir serializador e desserializador como classes internas estáticas na mesma classe. NB, usando ThreadLocal para segurança de thread de SimpleDateFormat.

public class DateConverter {

    private static final ThreadLocal<SimpleDateFormat> sdf = 
        ThreadLocal.<SimpleDateFormat>withInitial(
                () -> {return new SimpleDateFormat("yyyy-MM-dd HH:mm a z");});

    public static class Serialize extends JsonSerializer<Date> {
        @Override
        public void serialize(Date value, JsonGenerator jgen SerializerProvider provider) throws Exception {
            if (value == null) {
                jgen.writeNull();
            }
            else {
                jgen.writeString(sdf.get().format(value));
            }
        }
    }

    public static class Deserialize extends JsonDeserializer<Date> {
        @Overrride
        public Date deserialize(JsonParser jp, DeserializationContext ctxt) throws Exception {
            String dateAsString = jp.getText();
            try {
                if (Strings.isNullOrEmpty(dateAsString)) {
                    return null;
                }
                else {
                    return new Date(sdf.get().parse(dateAsString).getTime());
                }
            }
            catch (ParseException pe) {
                throw new RuntimeException(pe);
            }
        }
    }
}

(2) Como alternativa ao uso das anotações @JsonSerialize e @JsonDeserialize em cada membro da classe, você também pode substituir a serialização padrão de Jackson aplicando a serialização personalizada no nível do aplicativo, ou seja, todos os membros da classe do tipo Date serão serializados por Jackson usando essa serialização customizada sem anotação explícita em cada campo. Se você estiver usando o Spring Boot, por exemplo, uma maneira de fazer isso seria da seguinte maneira:

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

    @Bean
    public Module customModule() {
        SimpleModule module = new SimpleModule();
        module.addSerializer(Date.class, new DateConverter.Serialize());
        module.addDeserializer(Date.class, new Dateconverter.Deserialize());
        return module;
    }
}

Se alguém tiver problemas com o uso de um formato de data personalizado para java.sql.Date, esta é a solução mais simples:

ObjectMapper mapper = new ObjectMapper();
SimpleModule module = new SimpleModule();
module.addSerializer(java.sql.Date.class, new DateSerializer());
mapper.registerModule(module);

(Essa resposta SO me poupou muitos problemas: https://stackoverflow.com/a/35212795/3149048 )

Jackson usa o SqlDateSerializer por padrão para java.sql.Date, mas atualmente, esse serializador não leva em conta o formato da data, consulte este problema: https://github.com/FasterXML/jackson-databind/issues/1407 . A solução alternativa é registrar um serializador diferente para java.sql.Date, conforme mostrado no exemplo de código.

Quero salientar que definir um exemplo SimpleDateFormatdescrito na outra resposta só funciona para o java.util.Dateque eu suponho que se refira à pergunta. Mas para java.sql.Dateo formatador não funciona. No meu caso, não era muito óbvio por que o formatador não funcionou, porque no modelo que deveria ser serializado o campo era de fato um, java.utl.Datemas o objeto real acabou sendo um java.sql.Date. Isso é possível porque

public class java.sql extends java.util.Date

Então isso é realmente válido

java.util.Date date = new java.sql.Date(1542381115815L);

Portanto, se você está se perguntando por que o campo Data não está formatado corretamente, verifique se o objeto é realmente um java.util.Date.

Aqui também é mencionado por que o manuseio java.sql.Datenão será adicionado.

Isso seria quebra de mudança, e eu não acho que isso se justifique. Se estivéssemos começando do zero, eu concordaria com a mudança, mas como as coisas não são muito.