Хранение настенных часов в Джанго / Постгрес

Question

Я хочу сохранить дату и время будущих часов для событий в Джанго (строка часового пояса хранится отдельно).

Я не могу просто использовать DateTimeField, потому что он обеспечивает timestamp with time zone и всегда экономит время в текущем часовом поясе. Он не обрабатывает летнее время или возможные изменения часового пояса между текущей датой и датой фактического события.

Я мог бы использовать любую из следующих опций:

• Выберите любой часовой пояс для хранения временных отметок и всегда выбрасывайте этот часовой пояс перед применением фактического часового пояса в Python.
• Отметка времени разделения на DateField и TimeField.
• Сохранить дату и время как строку.
• Пользовательское поле, в котором дата и время хранятся как timestamp without time zone.

но это усложняет запросы и кажется довольно странным.

Есть ли лучшие варианты, которые я пропускаю? Этот сценарий использования довольно распространен, поэтому я думаю, что есть лучший способ сделать это?

РЕДАКТИРОВАТЬ: мой случай использования:

Допустим, мой пользователь хочет записаться на встречу на 2019-12-20 10:00, а сейчас это 2019-03-10. Я знаю часовой пояс этого пользователя (он хранится отдельно в виде строки, например, US / Eastern).

Если я предполагаю, что EST начинается 3 ноября 2019 года, лучшее, что я могу сделать, это сохранить метку времени в 2019-12-20 15:00:00+00:00 (или 2019-12-20 10:00-05:00. Я не хочу этого, потому что:

• Я понятия не имею, содержит ли моя tzdata правильную информацию для будущей даты и времени
• Даже если это происходит в настоящее время, я понятия не имею, произойдут ли какие-либо неожиданные изменения в часовом поясе США / Восточной Америки, и станет ли это хуже, если это не США. Будущие изменения летнего времени не гарантируются.
• Если пользователь переходит в другой часовой пояс, мне придется пересчитывать каждую встречу, заботясь о летнем времени.
• Если во время этого пересчета изменятся tzdata ... давайте не будем об этом думать.

Я бы предпочел хранить будущие даты как наивную строку datetime + timezone, такую ​​как 'US / Eastern', и (почти) никогда не создавать дату / время с учетом tz для любой даты, превышающей неделю. Django + postgres в настоящее время вынуждает меня использовать timestamp with time zone, что отлично подходит для журналов и прошлых событий, но имеет фиксированное смещение (даже не название часового пояса), поэтому оно не подходит для будущих настенных часов.

Для этого варианта использования, допустим, меня не волнуют неоднозначные времена: мало кто хочет бронировать в 02:00.

Answer 1

Я вижу несколько возможных решений:

1. Установите USE_TZ = False и TIME_ZONE = 'UTC' и используйте календарное время. Никаких преобразований не будет, поэтому, по сути, вы просто сохраняете календарное время и возвращаете его как наивную дату-время. Основная проблема заключается в том, что этот параметр является глобальным и не подходит для многих целей (например, auto_now).

2. Как указано выше, но установить USE_TZ = True. Пока вы указываете время в календаре в формате UTC, нежелательных преобразований не будет. Проблема в том, что вы будете знать дату и время, поэтому вам придется позаботиться о том, чтобы игнорировать или удалять часовой пояс везде.

3. Используйте отдельные DATE_FIELD и TIME_FIELD. Это может или не может быть хорошим решением в зависимости от того, какие запросы вы пытаетесь выполнить.

4. Создайте свое собственное поле, которое использует timestamp without time zone. (Или, может быть, уже существует ?)

Обратите внимание, что эта проблема не имеет ничего общего с прошлым и будущим. Речь идет о желании использовать фиксированный момент времени по сравнению с календарем (или настенными часами). Поднятые вами пункты, безусловно, являются веским возражением против использования момента времени для представления календарного времени.