Передача даты с формы в базу
Дано
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/. Там две ветки.