Обычно хранение временной точки в БД - это хранение числового long значения Unix-time.
При чтении - мы преобразуем long в объекты классов, которые должны работать со временем, при помощи конструктора.
Это самый удачный способ, который крайне сложно сломать или не так интерпретировать. БД в таком случае ничиего не знает о времени и никаких эффектов мы получить не сможем.
Если же избирается иной путь - т.е хранение времени в БД подразумевает операции в запросах и т.д - готовьтесь к работе с временными зонами. При этом надо четко понимать:
- Что за временная зона у сервера
- Что за временная зона у БД
- Что за временная зона у таблицы
- Что за временная зона у соединения
- Что за временная зона хранится вместе с временной меткой
При этом стандартные типы для хранения зависят от БД.
В случае MySQL существует два типа хранения времени:
- TIMESTAMP
- DATETIME
- DATE
Исходя из официальной документации:
MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval.
Т.е при получении из БД отображается с учетом часового пояса! Как было сказано выще - часовой пояс может быть задан в операционной системе, глобальных настройках MySQL или в конкретной сессии. При этом, сохраняется TIMESTAMP - как количество секунд по UTC.
DATETIME же отображается независимо от того, какой часовой пояс установлен в MySQL. Оно не зависит от временной зоны.
Это значит, что при смене временной зоны DATETIME не изменится.
Некоторые БД имеют такие типы хранения времени, которые кроме самой временной точки хранят дополнительную и информацию о временной зоне в которой она была введена.