Почему бы не запустить серверное приложение с включенным переходом на летнее время?

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

В целях безопасности, если приложение обнаруживает, что DST включен при запуске, регистрируется ошибка и приложение прекращает. Я подаю петицию от внутренних заинтересованных сторон, чтобы заставить приложение работать, даже если часы сервера приложений включают DST.

Я чувствую, что это безрассудная попытка, но мне нужно убедить руководство. Является ли это просто тем, что это делает реализацию более сложной или это фундаментально ущербно таким образом, что такое приложение (которое записывает метки времени) не может функционировать на 100% правильно во все времена года? Что является лучшим аргументом для того, чтобы не запускать такое приложение с Перехода на летнее время включена?

Лучшее, что я придумал, это:

Когда летнее время включено, есть два временных разрыва в год. Рассмотрим следующий сценарий, когда сервер работает в Великобритании с часами, установленными на местное время с включенным переходом на летнее время: В 2 часа ночи 25 октября 2009 года часы возвращаются на один час к 1 часу ночи. Запись создается в 1.30 утра.
  • приложение (которое должно хранить метки времени в UTC) не может сказать, является ли это 1.30 утра до или после часы вернулись назад, и поэтому не могут определить, следует ли включать дополнительный час в настройку на UTC.

    • Это правда? Действительно ли можно определить (в веб-приложении Java), является ли событие, которое происходит в 1.30 утра 25 октября, до или после настройки часов?

    Есть ли более веские причины избегать ДСТ?

    Обновить

    Просто для ясности, это данность, что приложение должно хранить раз как UTC. Вопрос в том, почему, когда пытаются для этого было бы плохой идеей включить DST на серверной машине.

    3 3
    server-side application-server

    3 ответа:

    Нет никаких причин запрещать DST на сервере, поскольку часовые пояса-это (или я должен сказать "должны быть") немного больше, чем форматирование. Системные часы являются агностиками часового пояса. Метки времени должны храниться в однозначном формате, либо в виде "тиков с эпохи", таких как System.currentTimeMillis() и иже с ними (которые являются временными зонами-агностиками), либо в виде текста с заданным смещением UTC (который затем становится однозначным, как ISO 8601).

    5

    Я обнаружил (из многих лет неудачного опыта), что лучше всего хранить даты и время в формате UTC и преобразовывать их в местное время только тогда, когда пользователь хочет их просмотреть.

    Кроме того, пусть пользователь вводит местное время, но преобразует его в UTC перед сохранением.

    Это избавит вас от всевозможных проблем в будущем, включая попытки выяснить, что происходит, когда ваши приложения распределены по нескольким часовым поясам.

    Если вы получаете и сохраняете только время UTC, то ДСТ не имеет значения.

    Одно особенно неприятное приложение, которое мы унаследовали, отправляло сообщения с местным временем с часовым поясом через часовые пояса, требуя много энергии, чтобы быть затраченным на их частую модификацию.

    Когда мы изменили его, чтобы использовать только UTC, он был намного лучше. Преобразование в UTC на одном конце было сделано как можно раньше, преобразование в местное время было отложено до последнего возможного момента. Код стал намного меньше и намного быстрее.

    14

    Пока вы используете встроенные классы Java для хранения дат и времени, DST не должен быть проблемой. Внутреннее представление времени - это "миллисекунды после полуночи, 1 января 1970 года, в Гринвиче Англия", поэтому то, в каком часовом поясе вы находитесь или действуете ли DST, не имеет значения.

    Никогда не пытайтесь сравнить две даты или время, используя текстовое представление, например "10/09/2009" или что-то еще. Используйте значение длинной миллисекунды. Сейчас я работаю над системой, в которой оригинальные авторы кажутся чтобы использовать другой метод каждый раз, когда они хотят сравнить две даты. В одном месте они выражают дату как гггг / ММ/ДД, затем убирают косые черты, преобразуют результат в целое число - так что 10.08.2009 становится 20.091 008 - и затем сравнивают их друг с другом. В других случаях они сравнивают их как текстовые строки. И т.д. Это дает неправильные результаты повсюду, когда задействовано несколько часовых поясов или DST.

    0