Можно ли убедить JDBC + MySQL игнорировать часовые пояса?

Question

У меня есть веб-приложение на Java, в котором клиент отправляет данные с метками времени на сервер для хранения в базе данных MySQL и последующего извлечения.Эти временные метки всегда должны рассматриваться как местное время и никогда не корректироваться для часового пояса: если клиент в одном часовом поясе вводит время 18:00:00, он должен отображаться для клиента в другом часовом поясе как 18: 00: 00.

Столбец базы данных, содержащий это значение, имеет тип DATETIME, так как у меня сложилось впечатление, что он не регулирует часовой пояс.Приложение java получает метки времени в виде объектов java.util.Date и преобразует их в объекты java.sql.Timestamp, прежде чем вставлять их в PreparedStatements.Однако где-то в пути значения времени смещаются, когда клиент и сервер находятся в разных часовых поясах.

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

Каков обычный способ обработки таких строк?приложения, когда значения меток времени всегда должны рассматриваться как местное время?

Answer 1

Настройте и сервер веб-приложений, и сервер базы данных на использование часового пояса GMT / UTC. Это сводится к тому, что вся база кода и все слои должны использовать один и тот же часовой пояс.

Связанный:

• Рекомендации по переходу на летнее время и часовой пояс

Answer 2

Вы должны иметь возможность принудительно устанавливать конкретную временную зону при чтении и записи в базу данных с помощью методов setTimestamp и getTimestamp, которые принимают объект Calendar .

Answer 3

MySQL или любая другая стандартная база данных не хранит информацию о часовом поясе.Он просто хранит смещение времени от эпохи.Клиент должен определить, какое время для определенного часового пояса.

Однако где-то по пути значения времени сдвигаются, когда клиент и сервер находятся в разных часовых поясах.

Конечно, так и должно быть.Если вы хотите принудительно установить обязательный часовой пояс, вы можете применить смещение часового пояса, которое вы хотите, прежде чем отправлять метку времени в экземпляр базы данных mysql (для этого вместо этого следует использовать стандартную библиотеку, такую ​​как страшная, встроенная в jdk или joda time).просто сложение или вычитание 1 часа).

Answer 4

Что бы я сделал, это сохранил бы временную метку как long, представляющую время по Гринвичу - таким образом, у MySQL нет возможности прикрутить его (и в качестве бонуса вы получите лучшую точность - временные метки MySQLс точностью до одной секунды).Добавьте отдельный столбец для хранения часового пояса, а затем преобразуйте его в строку местного времени перед отображением для пользователя.

Также остерегайтесь перехода на летнее время.В некоторых местах его нет, и он не всегда запускается и останавливается одновременно во всех местах, где он есть.

Answer 5

Проблема в том, что java.util.Date представляет «момент времени», а не время, как 18:00. (Момент времени в данном случае измеряется количеством миллисекунд с 1 января 1970 года 00:00:00 по Гринвичу, но в принципе это не имеет значения.)

Обычный способ (по крайней мере, так, как я всегда это делал) - сохранять точки во времени в базе данных, поэтому, если вы делаете что-то в 13:00, я вижу это, например, как. 3 часа дня, как в тот же момент времени в моем часовом поясе Таким образом, требование хранить «время» (ЧЧ: ММ) без сохранения «момента времени», то есть без корректировки на часовой пояс получателя, довольно необычно, по крайней мере, по моему опыту.

Я бы использовал тип данных DATETIME, который вы используете, но вставьте и прочитайте значения как строки из Java, т. Е. С помощью метода setString в PreparedStatement и getString в ResultSet.

Answer 6

Это старая ветка, но никто не отправил простой ответ. Вместо этого используйте поле TIMESTAMP. MySql не выполняет настройку часового пояса для TIMESTAMP, поэтому он будет работать для вас "из коробки".

Большинство подобных потоков пытаются обойти это отсутствие регулировки, но для вашего случая это хорошо сочетается с нужным вам поведением.