Возможно, вам стоит позаимствовать некоторые идеи из моей реализации дат начала/окончания действия ваучера в диалоговом окне «Новый ваучер» в системе электронной коммерции, над которой я работаю:
Другой пример, демонстрирующий гибкость и то, как мы избегаем неоднозначности в диапазонах дат в интерфейсе:
Технические детали: В нашем приложении мы всегда сохраняем даты как «timestamp with timezone» (в PostgreSQL), поэтому ни настройки базы данных, ни настройки подключения не могут повлиять на фактически сохранённый временной штамп. Хотя PostgreSQL не рекомендует этого делать, мы так поступаем, потому что это даёт 100% гарантию корректности даты в любой ситуации и в любом SQL-запросе. Вы можете работать с часовыми поясами дат прямо в PostgreSQL, используя их функции для работы с датой/временем/часовым поясом, и быть уверенными, что это будет работать абсолютно корректно всегда. Мы полагаемся на это.
Кроме того, у нас есть настройка часового пояса для всех типов сущностей, где это необходимо: профили пользователей, рынки, ваучеры, отчётность для бухгалтеров и так далее — это позволяет нам при необходимости переводить любые даты в любой часовой пояс без колебаний.
Основные выводы здесь следующие:
- Всегда храните дату и время вместе с часовым поясом.
- Всегда храните предпочтительный часовой пояс.
- Будьте очень явны в отображении дат в интерфейсе, не применяйте никаких «магических» преобразований.
- Позвольте пользователю увидеть фактические даты в выбранном часовом поясе перед нажатием кнопки «Сохранить».