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

Question

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

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

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

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

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

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

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

Обновление

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

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

Пока вы используете встроенные классы Java для хранения даты и времени, DST не должен быть проблемой.Внутреннее представление времени - это «миллисекунды после полуночи, 1 января 1970 года, в Гринвиче, Англия», так что в каком часовом поясе вы находитесь или действует ли DST, не имеет значения.Попробуйте сравнить две даты или время, используя текстовое представление, например, «10/09/2009» или что-то еще.Используйте значение длинной миллисекунды.Сейчас я работаю над системой, в которой авторы оригинала, кажется, используют другой метод каждый раз, когда хотят сравнить две даты.В одном месте они выражают дату как гггг / мм / дд, затем удаляют косые черты, преобразуют результат в целое число - таким образом, 10.08.2009 становится 20 091 008 - и затем сравнивают их друг с другом.В других случаях они сравнивают их как текстовые строки.И т.д. Это дает неверные результаты повсюду, когда задействованы несколько часовых поясов или летнее время.