Как узнать часовой пояс временной метки в postgresql 8.3

Question

Я использую postgresql 8.3, и я хотел бы знать часовой пояс конкретной временной метки (столбец в таблице).

В документации я нашел ключевое слово "часовой пояс"

Но я не понимаю, как применить это в столбце таблицы. Возможно ли это?

Answer 1

Я предполагаю, что у вас есть столбец с именем ct, который имеет тип TIMESTAMPTZ в таблице t. Тогда вы можете использовать:

SELECT EXTRACT(TIMEZONE FROM ct) FROM t;

, чтобы получить смещение часового пояса в секундах. Это то, что дает вам 3600 из UTC / GMT, что означает либо GMT+1, CET, либо что-то еще. Возвращаемое значение зависит от настроек TIMEZONE.

Пример (я живу в Германии, фактический часовой пояс ist GMT+1 / CET):

test=# select '2008-01-01 12:00:00 GMT+5'::timestamptz;
      timestamptz       
------------------------
 2008-01-01 18:00:00+01

test=# set timezone to 'gmt';
SET
test=# select '2008-01-01 12:00:00 GMT+5'::timestamptz;
      timestamptz       
------------------------
 2008-01-01 17:00:00+00

Как вы можете видеть, он всегда выводит что-либо в настроенном часовом поясе. Таким образом, смещение, которое вы получите с EXTRACT(TIMEZONE FROM ...), зависит от вашей настройки TIMEZONE. Часовой пояс, который был указан на INSERT, потерян, потому что его не стоит спасать. Важно то, что все правильно, и это не должно зависеть от настройки TIMEZONE. PostgreSQL делает это очень хорошо.

Answer 2

"PostgreSQL делает это очень хорошо."

Мне действительно нравится PostgreSQL, но в этой особенности он не очень хорошо работает. Часовой пояс смещен не только по Гринвичу. Часовой пояс тесно связан с политическими правилами, которые подразумевают переход на летнее время. Поскольку существует множество часовых поясов с одинаковым смещением и разными правилами перехода на летнее время - когда PG забывает о первоначальном часовом поясе, фактически теряет информацию.

Лично я храню исходный часовой пояс отдельно для дат, которые имеют значение, в форме «Америка / Нью-Йорк». Если у кого-то есть лучшее решение - добро пожаловать.

Answer 3

В Postgres исходный входной часовой пояс теряется, даже если вы сохраняете значение даты и времени в отметка времени с часовым поясом тип данных.

Неудобство:
Скажите, если у меня есть данные о времени и времени (вместе с информацией о часовом поясе) о том, когда люди используют приложение Facebook во всем мире. Теперь я храню эти значения в отметке времени с типом данных часового пояса . В один случайный день я хочу увидеть, насколько сильно люди используют свое приложение FB утром по сравнению с ночью, и наблюдается ли такая же тенденция в разных странах. Но подождите, у меня больше нет информации о часовом поясе. Находясь в округе Колумбия, я вижу, как эта деятельность распространилась по всему миру, когда было 10 утра по восточному поясному времени.

Преимущество:
Если вы сравниваете два источника данных с отметкой времени одного и того же часового пояса, но один был сохранен как то, что показывали местные часы, в то время как другие сохранялись путем преобразования его в UTC. Здесь вы можете просто сохранить метку времени в типе timestamptz и указать, к какому часовому поясу он относится, и затем вы можете легко сравнить их.
Например,
Активность в часовом поясе PST была зарегистрирована в 2014-10-19 10:23:54. Теперь два отдельных источника данных хранятся отдельно. Источник данных1 сохранил его как 2004-10-19 10:23:54 PST, Источник данных2 сохранил его как 2014-10-19 18:23:54 UTC. Если они хранятся в типе данных timestamptz , он покажет вам то же самое время, когда вы выполните

SELECT datasource1.time, datasource2.time 

Answer 4

Поскольку отметка времени записывается на мгновение во времени по времени ZULU / GMT, которое никогда не меняет своего смещения (поскольку оно является эталонным), нет необходимости записывать часовой пояс. Вам нужно только добавить / вычесть смещение к смещению часового пояса ГЕОПОЛИТИКИ в ПРОШЛОМ, НАСТОЯЩЕМ или БУДУЩЕМ.

Вы DO должны знать точную ГЕОПОЛИТИЧЕСКУЮ ВРЕМЕНИ, действующую в том месте, к которому относится время, к которому относится в данный момент, применяется в ПРОШЛОМ и НАСТОЯЩЕЕ целях.

Для будущих случаев во временных целях это может стать более проблематичным, возможно. Это все еще должно работать, хотя. Подумай о закате. Если в каком-то месте Земли время заката @ полночь ZULU (где-то над Атлантическим океаном или северной Канадой на Аляске зимой в Северном полушарии), и предполагается, что это время составляет 8 часов вечера (смещение -4: 00) в этом месте в в тот момент, когда вы записываете его в систему и записываете как «зима-дата-в-будущее в 8:00 вечера», он будет записан как 24:00 по Гринвичу в базе данных.

Теперь, это место на земле нарастает на * ss и теребит свой нос в расчете на географическое время и называет их часовой пояс - '+11: 55'. Поэтому для них, когда в Англии полночь (полночь по Гринвичу), они хотят назвать это 11:55, это их выбор. Когда какой-либо компьютер захочет отобразить эту дату в будущем для этого местоположения (то есть, этот геополитический часовой пояс), они назовут его 11:55, даже если солнце садится. И, конечно, это будет день впереди того дня, когда вы запланировали это :-) Их проблема.