Представление будущего времени в PostgreSQL

Ищите API-интерфейс анимации Matplotlib. Есть также некоторые примеры ...

0
задан bignose 27 February 2019 в 05:46
поделиться

2 ответа

Особенно , если вы хотите защитить себя от будущих изменений времени, вы должны использовать timestamp with time zone.

PostgreSQL внутренне хранит количество микросекунд с 2000-01-01 00:00:00, что безопасно от изменений часовых поясов. Если вы продолжаете обновлять свой PostgreSQL, он всегда будет правильно отображать это абсолютное значение для вашего часового пояса сеанса.

В PostgreSQL нет положения о дополнительных секундах.

0
ответ дан Laurenz Albe 27 February 2019 в 05:46
поделиться

Думайте [об этом] как событие календаря. UTC для этого не имеет смысла

Похоже, вы хотите сохранить местное время относительно определенного часового пояса. В этом случае сохраните timestamp (без часового пояса) и timezone в отдельном столбце.

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

Если база данных хранит метку времени без часового пояса:

unutbu=# select '2030-02-26 10:00:00'::timestamp as localtime, 'America/Chicago' AS tzone;
+---------------------+-----------------+
|      localtime      |      tzone      |
+---------------------+-----------------+
| 2030-02-26 10:00:00 | America/Chicago |
+---------------------+-----------------+

Затем, позже, вы можете найти дату и время события в формате UTC, используя

unutbu=# select '2030-02-26 10:00:00'::timestamp AT TIME ZONE 'America/Chicago' AT TIME ZONE 'UTC';
+---------------------+
|      timezone       |
+---------------------+
| 2030-02-26 16:00:00 |
+---------------------+

Запрос возвращает дату и время UTC, 2030-02-26 16:00:00, что соответствует 2030-02-26 10:00:00 местному времени в Чикаго.

Использование AT TIME ZONE задерживает применение правил часового пояса до момента выполнения запроса, а не когда был вставлен timestamptz.


Использование AT TIME ZONE в timestamp локализует дату и время для данного часового пояса, но сообщает дату и время в часовом поясе пользователя . Использование AT TIME ZONE для timestamptz преобразует дату и время в заданный часовой пояс, а затем сбрасывает смещение, возвращая, таким образом, timestamp. Выше AT TIME ZONE используется дважды: сначала для локализации timestamp, а затем для преобразования возвращенного timestamptz в новый часовой пояс (UTC). Результатом является timestamp в UTC.

Вот пример, демонстрирующий поведение AT TIME ZONE на timestamp с:

unutbu=# SET timezone = 'America/Chicago';
unutbu=# SELECT '2030-02-26 10:00:00'::timestamp AT TIME ZONE 'America/Chicago';
+------------------------+
|        timezone        |
+------------------------+
| 2030-02-26 10:00:00-06 |
+------------------------+

unutbu=# SET timezone = 'America/Los_Angeles';
unutbu=# SELECT '2030-02-26 10:00:00'::timestamp AT TIME ZONE 'America/Chicago';
+------------------------+
|        timezone        |
+------------------------+
| 2030-02-26 08:00:00-08 |
+------------------------+

2030-02-26 10:00:00-06 и 2030-02-26 08:00:00-08 являются одинаковыми датами, но сообщаются в разных часовых поясах пользователя. Это показывает, что 10:00 в Чикаго - это 8:00 в Лос-Анджелесе (с использованием текущих определений часовых поясов):

unutbu=# SELECT '2030-02-26 10:00:00-06'::timestamptz AT TIME ZONE 'America/Los_Angeles';
+---------------------+
|      timezone       |
+---------------------+
| 2030-02-26 08:00:00 |
+---------------------+

Альтернативой двойному использованию AT TIME ZONE является установка часового пояса пользователя в UTC. Тогда вы можете использовать

select localtime AT TIME ZONE tzone

. Обратите внимание, что когда это сделано, вместо timestamp возвращается timestamptz.


Помните, что хранение локальных времен может быть проблематичным, поскольку могут существовать несуществующие и неоднозначные времена. Например, 2018-03-11 02:30:00 - это несуществующее местное время в America/Chicago. Postgresql нормализует несуществующие локальные времена, предполагая, что оно относится к соответствующему времени после начала перехода на летнее время (DST) (как если бы кто-то забыл перевести свои часы вперед):

unutbu=# select '2018-03-11 02:30:00'::timestamp AT TIME ZONE 'America/Chicago' AT TIME ZONE 'UTC';
+---------------------+
|      timezone       |
+---------------------+
| 2018-03-11 08:30:00 |
+---------------------+
(1 row)

unutbu=# select '2018-03-11 03:30:00'::timestamp AT TIME ZONE 'America/Chicago' AT TIME ZONE 'UTC';
+---------------------+
|      timezone       |
+---------------------+
| 2018-03-11 08:30:00 |
+---------------------+
(1 row)

Примером неоднозначного местного времени является [ 1133] в America/Chicago. Это происходит дважды из-за летнего времени. Postgresql разрешает эту неоднозначность, выбирая более позднее время после окончания летнего времени:

unutbu=# select '2018-11-04 01:00:00'::timestamp AT TIME ZONE 'America/Chicago' AT TIME ZONE 'UTC';
+---------------------+
|      timezone       |
+---------------------+
| 2018-11-04 07:00:00 |
+---------------------+

Обратите внимание, что это означает, что нет способа сослаться на 2018-11-04 06:00:00 UTC путем сохранения локальных времен в часовом поясе America/Chicago: [1156 ]

unutbu=# select '2018-11-04 00:59:59'::timestamp AT TIME ZONE 'America/Chicago' AT TIME ZONE 'UTC';
+---------------------+
|      timezone       |
+---------------------+
| 2018-11-04 05:59:59 |
+---------------------+
0
ответ дан unutbu 27 February 2019 в 05:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: