Комментарии 6
В ответ возвращать дату и время с указанием серверного часового пояса
Кажется странным, что клиент отдает время со своим часовым поясом, а в ответ получает с часовым поясом сервера. Т.е. получается, что на клиенте все равно есть преобразование серверного пояса в клиентский? Если так, то не проще и при отправке на сервер тоже отправлять сразу с серверным часовым поясом? К слову, часто так и делают. Хранят все в utc и на клиенте приводят к нужному виду.
Поддержу. Имхо, всегда лучше стараться исключить сервере время как таковое: использовать или время по UTC (Instant), или локальное по отношению к клиенту/источнику запроса/т.п.
Сам по себе подход не рекомендация к действию. А ситуации могут быть разные. К примеру, требования со стороны клиента
Если кому-нибудь понадобится де/сериализация отдельного поля:
@JsonFormat(shape=JsonFormat.Shape.STRING, pattern=«yyyy-MM-dd'T'HH:mm:ss.SSSZ», timezone=«America/Phoenix»)
private Date date;
Используйте grpc и timestamp proto message и вам не надо будет решать бородатые проблемы, включая awkward json serialization и изживший себя Jackson mapper.
И да, время ВСЕГДА хранится в utc, даже если вы решите остаться с json.
Решение сложное, низкопроизводительное и имеет баги.
В вашем решении вы передаёте текущую дату методу getOffset. Если временная зона предполагает DST и между обрабатываемым и текущим временем был переход на зимнее/летнее время, возникнет ошибка.
Также я бы вообще воздержался от использования ZoneOffset.systemDefault().getRules(), так как он порождает лишние объекты, в частности тяжёлый ConcurrentHashMap.
Я бы сохранил в статическое поле следующий форматтер: var fmt = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ssxxx");, использовать его так: localDateTime.atZone(ZoneId.systemDefault()).format(fmt)
Кастомная (де) сериализация даты и времени в Spring