В PostgreSQL/JDBC и метки и TIMESTAMPTZ
в последнее время я испытываю много боли, имея дело с временными метками с JPA. Я обнаружил, что многие мои проблемы были устранены с помощью TIMESTAMPTZ для моих полей вместо метки времени. Мой сервер находится в UTC, а мой JVM - в PST. Кажется почти невозможным с JPA нормализовать значения UTC в базе данных при использовании метки времени без часового пояса.
для меня я использую эти поля для таких вещей, как "когда был создан пользователь", " когда они в последний раз использовали свое устройство", "когда в последний раз они получали предупреждение" и т. д. Обычно это события, поэтому они являются экземплярами во временных видах значений. И потому, что теперь они будут TIMESTAMPTZ я всегда могу запросить их для определенной зоны, если я не хочу их UTC.
Итак, мой вопрос: для сервера Java/JPA/PostgreSQL, когда я хотел бы использовать метку времени над TIMESTAMPTZ? Каковы варианты его использования? Прямо сейчас мне трудно понять, почему я когда-либо хотел использовать TIMESTAMP, и из-за этого я обеспокоен что я не понимаю его ценности.
2 ответов
Вы можете использовать его для представления того, что Joda-Time и новый Java 8 time APIs называют LocalDateTime. А LocalDateTime не представляет точную точку на временной шкале. Это просто набор полей, от года до наносекунд. Это "описание даты, как дни рождения, в сочетании с местным временем, как видно на стене часы".
Вы можете использовать его, чтобы представить, например, тот факт, что ваша точная дата рождения 1975-07-19 в 6 вечера. Или, что по всему миру, новые год отмечается 2015-01-01 в 00: 00.
чтобы представить точные моменты, такие как момент, когда Армстронг ходил по Луне, метка времени с часовым поясом действительно более уместна. Независимо от часового пояса JVM и часового пояса базы данных, он должен вернуть вам правильный момент.
обычно используйте TIMESTAMPZ
вот совет от Дэвида Уилера, эксперта Postgres, в блоге, название которого говорит все:
всегда используйте метку времени с часовым поясом (TIMESTAMPZ)
если вы отслеживаете фактические моменты, конкретные точки на временной шкале, используйте TIMESTAMP WITH TIME ZONE.
Одно Исключение: Разделение
единственным исключением Уилера является разбиение на временные метки из-за технических ограничений. Ля редкое исключение для большинства из нас.
сведения о секционировании см. В разделе doc и видим Wiki.
неправильно
имена типов данных timestamp with time zone и timestamp without time zone неправильно употреблять. В и случаи значение даты и времени хранится в формате UTC (без смещения часового пояса). Прочтите предыдущее предложение еще раз. UTC, всегда. "С часовой пояс" фраза означает "со времени zone", а не"хранить часовой пояс рядом с этим значением". Разница между типами заключается в том, следует ли применять часовой пояс во время хранения (вставка или обновление) или извлечения (выбор запроса). (Это поведение описано для Postgres -- другие базы данных различаются широкое в этой связи.)
точнее, следует сказать, что отметка времени без часового пояса хранит значения даты и времени без часового пояса. Но без каких-либо временных рамок, кто-то смотрит на это данные должны были бы предположить (надеюсь, молю?) что значения UTC. Но опять же, спорный, как вы почти никогда не должны использовать этот тип.
читать док тщательно, и поэкспериментируйте немного, чтобы прояснить ваше понимание.
без зон
если вы хотите сохранить общее представление о возможном времени, а не конкретный момент, используйте другой тип, TIMESTAMP WITHOUT TIME ZONE.
например, Рождество начинается в этом году в первый момент 25 декабря, 2017. Это было бы 2017-12-25T
00:00:00 без индикатора часового пояса или смещения от UTC. Эта ценность - лишь смутное представление о возможных моментах. Это не имеет значения, пока мы не применяем часовой пояс (или смещение). Поэтому мы храним это, используя TIMESTAMP WITHOUT TIME ZONE.
эльфы укомплектование Санта-Клауса Отдел Логистики Специальных Мероприятий примените часовые пояса как часть процесса планирования. Самый ранний часовой пояс в настоящее время Pacific/Kiribati, на 14 часов раньше UTC. Расписание эльфы Санты первое прибытие туда. Эльфы планируют план полета, принимая оленей на другие часовые пояса, где полночь приходит вскоре после этого, такие как Pacific/Auckland. Они продолжают идти на Запад, когда наступает полночь каждой зоны. Часов в Asia/Kolkata, затем в Europe/Paris, еще больше часов в America/Montreal и так далее.
каждый из этих конкретных моментов доставки будет записан эльфами с помощью WITH TIME ZONE, в то время как эта общая идея Рождества будет храниться как WITHOUT TIME ZONE.
другое использование в бизнес-приложениях для WITHOUT TIME ZONE планирование встреч дальше, чем несколько недель. Политики во всем мире имеют необъяснимое пристрастие к возне с часами и переопределению правил часового пояса. Они присоединяются к летнему времени (DST), оставляют DST, начинают DST на другую дату или заканчивают DST на другую дату или сдвигают свои часы на 15 минут или полчаса. Все это было сделано за последние несколько лет Турцией, США, Россией, Венесуэла и другие.
политики часто делают эти изменения с небольшим предупреждением. Поэтому, если вы планируете стоматологическое назначение в течение шести месяцев в 13: 00, это, вероятно, должно храниться как TIMESTAMP WITHOUT TIME ZONE или иначе политики могут эффективно изменить вам назначение на полдень, или 2 часа дня, или 13:30.