Передача даты с формы в базу

Дано

Angular, PrimeNG, Spring Boot, JDBC, PostgreSQL

Надо

Передавать дату с формы в базу и обратно

Подготовка

create database test_date;

CREATE TABLE test_table ( 	test_date date NULL, 	test_timestamp timestamp NULL, 	test_timestamptz timestamptz NULL, 	id serial2, 	CONSTRAINT test_table_pk PRIMARY KEY (id) );

java.util.Date

Решение 1

Надо сохранять только дату без времени. Использую колонку с типом date.

Выбираю на форме дату 2020-12-22. На сервер отправится 2020-12-21T21:00:00.000Z. Это текущее время по UTC, так как браузер в зоне +3. Java сделает запрос

statement.setObject(1, entity.getTestDate(), Types.DATE)

insert into test_table (test_date) values ('2020-12-22 +03')

Java отбрасывает время и передает автоматически таймзону (по умолчанию зона сервера или -Duser.timezone=Europe/Moscow). Postgres не учитывает зону для типа данных date. Будет сохранено 2020-12-22. При чтении из базы вернется эта же дата. В Json попадет

{ "testDate": "2020-12-22" }

Браузер прочитает такой формат, как начало дня по UTC.

new Date('2020-12-22') new Date('2020-12-22T00:00:00.000+00:00') Tue Dec 22 2020 03:00:00 GMT+0300 (Moscow Standard Time)

Т.е на форме отображается 2020-12-22 03:00 или просто без времени 2020-12-22. Все верно.

Я встречал ситуацию , когда Chrome и Firefox интерпретировали дату без времени по-разному. Кто-то как начало дня по локальному времени. В данный момент такое не воспроизводится на обновленных версиях. Документация говорит, что сейчас такой формат стандартизирован. Но если строка отличается от формата 2020-12-22T00:00:00.000+00:00, то поведение не гарантировано.

Ошибка всплывет только если начнет тестировать пользователь, который восточнее часового пояса сервера. Например Europe/Samara (+4). Выберет на форме 2020-12-22. На сервер отправится 2020-12-21T20:00:00.000Z (2020-12-22 00:00 +4). Сервер (работает в зоне +3) переведет это в 2020-12-21T23:00:00.000+03:00, отбросит время и сохранит как

insert into test_table (test_date) values ('2020-12-21 +03')

При чтении сервер отдаст 2020-12-21, что превратится в 2020-12-21 04:00. На форме видим 2020-12-21. Ошибка.

Решение 2

При сохранении в БД указать временную зону пользователя, а не зону сервера.

statement.setDate(1, new java.sql.Date(entity.getTestDate().getTime()),     Calendar.getInstance(TimeZone.getTimeZone(userZoneId)));

Получить её можно отдельным параметром в запросе. Для этого в JS можно выполнить.

Intl.DateTimeFormat().resolvedOptions().timeZone;

Можно попробовать с полифилом новый API Temporal.now().timeZone().id. Этот параметр должен содержать зону по умолчанию. На старых браузерах может не работать или возвращать неправильную зону.

Запрос на сервер:

{"testDate":"2020-12-21T20:00:00.000Z","zoneId":"Europe/Samara"}

Сохранение:

insert into test_table (test_date) values ('2020-12-22 +04')

Зная зону, драйвер преобразовал 2020-12-21T23:00:00.000+03:00 в 2020-12-22T00:00:00.000+04:00, и сформировал строку 2020-12-22 +04. При чтении получится 2020-12-22 -> 2020-12-22 04:00:00. На форме видим 2020-12-22. Все верно.

Теперь протестируем ситуацию, когда пользователь к западу от UTC. Например America/Chicago (-6). Сохранится выбранная дата 2020-12-22. При чтении сервер отдаст её обратно, но она превратится в 2020-12-21 18:00 по местному времени пользователя и отобразится как 2020-12-21.

Решение 3

Надо , чтобы сервер отдавал дату с временем 2020-12-22T00:00:00.000 и без зоны, тогда это будет преобразовано браузером в начало дня по местному времени. Для этого сделаю сериалайзер даты

import java.text.SimpleDateFormat; import com.fasterxml.jackson.core.JsonGenerator; import com.fasterxml.jackson.databind.JsonSerializer; import com.fasterxml.jackson.databind.SerializerProvider;  public class DateSerializer extends JsonSerializer<Date> {    private final static SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");    @Override   public void serialize(Date value, JsonGenerator gen, SerializerProvider serializers) throws IOException {     gen.writeString(format.format(value));   } }

Теперь все верно. Выбранная пользователем дата сохраняется в БД правильно. И возвращается на форму правильно. Проверено на разных таймзонах. Можно на прод.

С прода приходит баг. Пользователи видят неправильную дату. И смещение не на один день, а вообще не та дата.

Решение 4

Метод java.text.SimpleDateFormat.format() не потокобезопасный. А я создал его один раз на все приложение. Надо для каждой сериализации делать свой экземпляр.

private static final String format = "yyyy-MM-dd'T'HH:mm:ss";  @Override public void serialize(Date value, JsonGenerator gen, SerializerProvider serializers) throws IOException {   gen.writeString(new SimpleDateFormat(format).format(value)); }

Получился сервис со странным интерфейсом для сохранения даты. В другом клиенте придется передавать не только дату, но и рассчитывать время и передавать зону, для которой это время рассчитано. Если я захочу сохранить 2020-12-22, то мне надо сначала определится с зоной. Если это +3, то надо передавать

{"testDate":"2020-12-21T21:00:00.000Z","zoneId":"Europe/Moscow"}

или

{"testDate":"2020-12-22T00:00:00.000+03:00","zoneId":"Europe/Moscow"}

В последнем варианте вообще получилось дублирование нужной информации о смещении. Надо убрать из запроса зону и оставить дату в формате 2020-12-22. Если придет 2020-12-21T21:00:00.000Z, то игнорировать время с зоной — сохранять как 2020-12-21). Возвращаться результат должен тоже без времени.

Решение 5

Убираю свой сериалайзер из java. На фронте надо обработать 2020-12-22 без времени, чтобы это было начало дня по локальному времени.

const ymd: string[] = obj.testDate.split('-'); const date: Date = new Date(ymd);

Это удобно и оно работает в Chrome и Firefox. Но конструктор с параметром Array не описан в стандарте. Поэтому параметр будет преобразован в строку и передан в Date.parse(). А этот метод стандартно работает только для 2020-12-22.

Поэтому напишу по стандарту

const ymd: number[] = obj.testDate.split('-').map((s: string) => Number(s)); const date: Date = new Date(ymd[0], ymd[1] - 1, ymd[2])

Следующим шагом надо отбрасывать время при сохранении. Это уже делает JDBC. Но это вызывает ошибку для пользователей с востока. Так как время отбрасывается от даты по серверному времени. Поэтому время надо отбрасывать до конвертации строки в дату по серверному времени. Тут появляется ещё проблема: браузер отправляет дату, как начало дня по времени UTC. Т.е код надо писать ещё перед отправкой на фронте.

public saveEntity(entity: TestEntity): Observable<number> {   const date: Date = entity.testDate;   const testDate: string = [date.getFullYear(), date.getMonth() + 1, date.getDate()]     .map(n => String(n).padStart(2, '0')).join('-');   const body: any = Object.assign({}, entity, {testDate});   return this.http.post<number>(CONTROLLER, body); }

Такой вариант работает, для пользователей из всех зон работает. И не надо ничего программировать на сервере.

Потом на проекте появляется разработчик из Чикаго. И тестирует приложение у себя. На сервер отправляется 2020-12-22. Сервер превращает это в 2020-12-21 18:00:00 по местному времени. И сохраняет

insert into test_table (test_date) values ('2020-12-21 -06')

Ошибка. Решение работает только для сервера к востоку от UTC.

Решение 6

Самое простое решение — захардкодить зону приложения.

System.setProperty("user.timezone", "UTC")

Но не совсем правильное. Что делать, если в приложении уже куча логики зависит от того, что сервер находится где-то по местному времени на западе? Проблема в том, что Jackson воспринимает полученную дату как начало дня по UTC. A я хотел, чтобы дата была началом дня для сервера.Тогда надо захардкодить эту зону и указать Jackson, что для конвертации надо использовать зону сервера.

public static final String APP_TIMEZONE = "America/Chicago"; public static void main(String[] args) {     System.setProperty("user.timezone", APP_TIMEZONE);     SpringApplication.run(TestDateApplication.class, args); }

import com.fasterxml.jackson.annotation.JsonFormat;  public class TestEntity {      @JsonFormat(timezone = TestDateApplication.APP_TIMEZONE,                 pattern = "yyyy-MM-dd")     private Date testDate;

Так как браузер теперь передает только дату без времени. То можно ограничить интерфейс и не позволять формат с временем. Если кто-то начнет передавать время, значит возможна ошибка с временными зонами.

Решение 7

Jackson пропускает такие даты, не учитывая время. Поэтому надо писать свой десериалайзер. Он будет выбрасывать исключение, если строка длиннее заданного формата.

import java.io.IOException; import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.Date;  import com.fasterxml.jackson.core.JsonParser; import com.fasterxml.jackson.core.JsonProcessingException; import com.fasterxml.jackson.core.JsonToken; import com.fasterxml.jackson.databind.DeserializationContext; import com.fasterxml.jackson.databind.JsonDeserializer; import com.fasterxml.jackson.databind.exc.InvalidFormatException;  public class DateDeserializer extends JsonDeserializer<Date> {      private static final String format = "yyyy-MM-dd";      @Override     public Date deserialize(JsonParser p, DeserializationContext ctxt)             throws IOException, JsonProcessingException {         if (p.hasToken(JsonToken.VALUE_STRING)) {             String text = p.getText().trim();             if (text.length() != format.length()) {                 throw new InvalidFormatException(p, "Wrong date", text, Date.class);             }             try {                 Date result = new SimpleDateFormat(format).parse(text);                 return result;             } catch (ParseException e) {                 throw new InvalidFormatException(p, "Wrong date", text, Date.class);             }         }         return (Date) ctxt.handleUnexpectedToken(Date.class, p);     } }

Если сохранить дату на востоке, а открыть на западе, то она будет одинакова. Но на западе может быть еще только вчера. Это может быть принято за ошибку. Зависит от задачи. Если речь о дате рождения, то ошибки нет. Если о дате публикации новости, то читатель на западе увидит новость из будущего. Это может выглядеть странно.

Решение 8

Для такого случая придется сохранять время вместе с датой. От времени зависит, одинаковая дата для разных часовых поясов в это время или разная. Для сохранения можно использовать два типа: timestamp или timestamp with time zone. Зону мне хранить, вроде бы, не надо, поэтому сделаю timestamp.

private static final String COLUMN_LABEL = "test_timestamp";  entity.setTestDate(rs.getTimestamp(COLUMN_LABEL));  statement.setTimestamp(1, new Timestamp(entity.getTestDate().getTime()));

С фронта поступит дата 2020-12-21T20:00:00.000Z. Будет передана в базу как

insert into test_table (test_timestamptz) values ('2020-12-21 14:00:00-06')

И сохранена в базе как время 2020-12-21 14:00:00. На фронт придет время с указанием зоны 2020-12-21T20:00:00.000+00:00 и будет показано локальное время. Работает.

Беда придет, если изменится таймзона сервера. Время в базе сохранено по зоне сервера. При чтении на сервере с другой таймзоной будет неправильное время. Из 2020-12-21 14:00:00 на сервере Europe/Moscow получится 2020-12-21T11:00:00.000+00:00. А должно было быть 2020-12-21T20:00:00.000+00:00.

Решение 9

Либо сервер должен быть всегда в одной зоне. Либо надо хранить даты в одной зоне и явно это указывать. Так как сервер был раньше в America/Chicago и время сохранено в такой зоне, то я укажу эту зону

private static final String COLUMN_TIMEZONE = "America/Chicago";  entity.setTestDate(rs.getTimestamp(COLUMN_LABEL,     Calendar.getInstance(TimeZone.getTimeZone(COLUMN_TIMEZONE))));  statement.setTimestamp(1, new Timestamp(entity.getTestDate().getTime()),     Calendar.getInstance(TimeZone.getTimeZone(COLUMN_TIMEZONE)));

Чтобы было легче дебажить, лучше сделать зону UTC. И в базе перевести время на UTC.

update test_table set test_timestamp =     (test_timestamp at time zone 'America/Chicago') at time zone 'UTC';

private static final String COLUMN_TIMEZONE = "UTC";

С фронта поступит дата 2020-12-21T20:00:00.000Z. Будет передана в базу как

insert into test_table (test_timestamp) values ('2020-12-21 20:00:00+00')

И сохранена в базе как время 2020-12-21 20:00:00. При чтении сервер получит 2020-12-21 14:00:00 по своему времени (-6). На фронт придет время с указанием зоны 2020-12-21T20:00:00.000+00:00 и будет показано локальное время.

Решение 10

Получилось тоже самое, что можно было сделать сразу, используя timestamp with time zone. Данный тип не хранит зону. Он хранит время для зоны UTC и автоматически конвертирует его во время для другой зоны. Поэтому код можно переписать без указания зоны при сохранении и чтении.

private static final String COLUMN_LABEL = "test_timestamptz";  entity.setTestDate(rs.getTimestamp(COLUMN_LABEL));  statement.setTimestamp(1, new Timestamp(entity.getTestDate().getTime()));

С фронта поступит дата 2020-12-21T20:00:00.000Z. Будет передана в базу как

insert into test_table (test_timestamptz) values ('2020-12-21 14:00:00-06')

И сохранена в базе независимо от зоны сервера как время 2020-12-21T20:00:00.000Z. При чтении сервер получит 2020-12-21 14:00:00 по своему времени. На фронт придет время с указанием зоны 2020-12-21T20:00:00.000+00:00 и будет показано локальное время.

Решение 11

Надо чтобы время показывалось всегда то, что ввели, и не зависело от временной зоны браузера или сервера. Для передачи по сети буду использовать формат без указания зоны. Для хранения буду использовать колонку timestamp.

public saveEntity(entity: TestEntity): Observable<number> { 	const date: Date = entity.testDate; 	const testDate: string = [date.getFullYear(), date.getMonth() + 1, date.getDate()] 		.map(n => String(n).padStart(2, '0')).join('-') 		+ 'T' + [date.getHours(), date.getMinutes(), date.getSeconds()] 		.map(n => String(n).padStart(2, '0')).join(':'); 	const body: any = Object.assign({}, entity, {testDate}); 	return this.http.post<number>(CONTROLLER, body); }

@JsonDeserialize(using = DateDeserializer.class) @JsonFormat(pattern = "yyyy-MM-dd'T'HH:mm:ss", timezone = TestDateApplication.APP_TIMEZONE) private Date testDate;

В десериалайзере:

Date result = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss").parse(text);

При выборе на форме 2020-12-22 14:14 отправится 2020-12-22T14:14:00. Это воспринимается как локальное время. И будет отправлено в базу.

insert into test_table (test_timestamp) values ('2020-12-22 14:14:00+04')

Так как тип колонки timestamp without time zone, то переданная зона просто будет отброшена, и дополнительной конвертации не будет. При чтении все также. Отобразится тоже, что сохраняли, в любом часовом поясе.

new Date('2020-12-22T14:14:00') Tue Dec 22 2020 14:14:00 GMT-0600 (Central Standard Time)

Time API

Решение 1

Сохраняю только дату. Колонка date. Тип поля DTO LocalDate.

private LocalDate testDate;  statement.setObject(1, entity.getTestDate(), Types.DATE);  entity.setTestDate(rs.getObject("test_date", LocalDate.class));

Выберу на форме 2020-12-22. От браузера придет 2020-12-21T21:00:00.000Z. Jackson превратит это в LocalDateTime для зоны UTC и отбросит время.

insert into test_table (test_date) values ('2020-12-21'::date)

В браузер вернется 2020-12-21. Неверно.

new Date('2020-12-21') Mon Dec 21 2020 03:00:00 GMT+0300 (Moscow Standard Time)

Решение 2

Надо делать десериализацию с таймзоной сервера.

public LocalDate deserialize(JsonParser p, DeserializationContext ctxt)         throws IOException, JsonProcessingException {     if (p.hasToken(JsonToken.VALUE_STRING)) {         String text = p.getText().trim();         try {             DateTimeFormatter formatter = new DateTimeFormatterBuilder()                     .append(DateTimeFormatter.ISO_LOCAL_DATE_TIME)                     .appendZoneId()                     .toFormatter();             LocalDate result = ZonedDateTime.parse(text, formatter)                     .withZoneSameInstant(ZoneId.systemDefault())                     .toLocalDate();             return result;         } catch (Exception e) {             throw new InvalidFormatException(p, "Wrong date", text, Date.class);         }     }     return (LocalDate) ctxt.handleUnexpectedToken(LocalDate.class, p); }

Теперь сохраняется введенная дата.

insert into test_table (test_date) values ('2020-12-22'::date)

Но это не будет работать для пользователя восточнее сервера.

Решение 3

Можно пойти путем передачи зоны пользователя. Тогда надо сменить тип поля на тип с временем: LocalDateTime.

String zoneId = entity.getZoneId(); statement.setObject(1,     ZonedDateTime.of(entity.getTestDate(), ZoneId.systemDefault())     .withZoneSameInstant(ZoneId.of(zoneId))     .toLocalDate(),     Types.DATE);  entity.setTestDate(     LocalDateTime.of(rs.getObject(COLUMN_LABEL, LocalDate.class), LocalTime.MIN));

Обратно с сервера вернется дата уже с временем 2021-12-22T00:00:00. Поэтому это решение будет работать и для пользователей с запада от UTC.

Решение 4

Если формировать дату без времени на фронте, то на сервере можно оставить только поле с типом LocalDate. И больше не делать дополнительных конвертаций.

statement.setObject(1, entity.getTestDate(), Types.DATE);  entity.setTestDate(rs.getObject(COLUMN_LABEL, LocalDate.class));

Это решение работает, если даже переместить сервер в другую зону.

Чтобы предотвратить ошибку из-за передачи даты в формате ISO по времени UTC, достаточно указать формат. На дополнительные символы будет ругаться.

@JsonFormat(pattern = "yyyy-MM-dd") private LocalDate testDate;

Решение 5

Чтобы сохранить время можно использовать LocalDateTime. Но для конвертации строки 2020-12-21T20:00:00.000Z в локальное время нужен десериалайзер с использованием ZoneDateTime. Поэтому буду использовать сразу его.

statement.setObject(1,     entity.getTestDate()         .withZoneSameInstant(ZoneId.systemDefault())         .toLocalDateTime(),     Types.TIMESTAMP);  entity.setTestDate(     ZonedDateTime.of(         rs.getObject(COLUMN_LABEL, LocalDateTime.class),         ZoneId.systemDefault()         )     );

При изменении зоны сервера даты поедут.

Решение 6

Укажу явно зону UTC для хранения времени.

private static final String COLUMN_TIMEZONE = "UTC";  statement.setObject(1,     entity.getTestDate()       .withZoneSameInstant(ZoneId.of(COLUMN_TIMEZONE))       .toLocalDateTime(),     Types.TIMESTAMP);  entity.setTestDate(     ZonedDateTime.of(         rs.getObject(COLUMN_LABEL, LocalDateTime.class),         ZoneId.of(COLUMN_TIMEZONE)         )     );

Решение 7

Теперь можно перейти на тип колонки timestamptz.

Чтобы сохранить ZonedDateTime в такую колонку, можно использовать LocalDateTime, но обязательно сконвертировав в зону сервера. Потому что JDBC сам добавит в запрос смещение на основе зоны сервера. Postgres его учтет для конвертации в UTC.

statement.setObject(1,     entity.getTestDate()       .withZoneSameInstant(ZoneId.systemDefault())       .toLocalDateTime());

insert into test_table (test_timestamptz) values ('2020-12-21 23:30:00+03'::timestamp)

Можно сохранять OffsetDateTime. Тогда будет передано то, что пришло из браузера.

statement.setObject(1, entity.getTestDate().toOffsetDateTime());

insert into test_table (test_timestamptz) values ('2020-12-21 20:30:00+00'::timestamp with time zone)

Читать из базы драйвер позволяет только в OffsetDateTime.

entity.setTestDate(     rs.getObject(COLUMN_LABEL, OffsetDateTime.class).toZonedDateTime()     );

Поэтому поле DTO можно сразу переделать в OffsetDateTime.

Решение 8

Для сохранение выбранного времени и отображения его независимо от зоны браузера достаточно передавать на сервер локальное время.

public saveEntity(entity: TestEntity): Observable<number> {   const date: Date = entity.testDate;   const testDate: string =     [date.getFullYear(), date.getMonth() + 1, date.getDate()]       .map(n => String(n).padStart(2, '0')).join('-')     + 'T'     + [date.getHours(), date.getMinutes(), date.getSeconds()] 		  .map(n => String(n).padStart(2, '0')).join(':');   const body: any = Object.assign({}, entity, {testDate});   return this.http.post<number>(CONTROLLER, body); }

На сервере использовать LocalDateTime и timestamp. Дополнительная настройка Jackson не нужна. При передаче времени с зоной он будет ругаться.

statement.setObject(1, entity.getTestDate());  entity.setTestDate(rs.getObject(COLUMN_LABEL, LocalDateTime.class));

Заключение

Чтобы избежать некоторых ошибок, надо изначально договорится о некоторых вещах. Формат даты в запросе и ответе. Зона, в которой будет запущен сервер. Зона, в которой хранится время.

Дополнительные ошибки могут появится, из-за устаревшей tzdata. PostgreSQL имеет свою tzdata. Если есть колонки timestamptz, то эта база используется. Надо обновлять минорные релизы. PostgreSQL может быть собран с флагом with-system-tzdata. Тогда надо обновлять системные зоны. Java имеет свою tzdata. Надо тоже обновлять. Можно отдельно от всей jre. Joda-time имеет свою tzdata.

Все решения доступны в репозитории https://github.com/Qwertovsky/test_date/commits/. Там две ветки.