Также ответили на Что должен знать каждый разработчик о времени (включая скриншоты со ссылками).
Поскольку летнее время заканчивается сегодня, я подумал, что это хорошее время для публикации,Как обращаться со временем - одна из тех хитрых проблем, когда слишком легко ошибиться.Итак, давайте углубимся. (Примечание. Мы извлекли эти уроки, когда внедрили систему планирования в Windward Reports.)
Во-первых, использование UTC (также известного как время по Гринвичу) часто не является правильным решением.Тем не менее, многие программисты думают, что если они все хранят таким образом, то им это удается.(Эта ошибка - то, почему несколько лет назад, когда Конгресс изменил начало летнего времени в США, вам пришлось запустить исправление в Outlook, чтобы он корректировал повторяющиеся события.)
Итак, давайте начнем с ключевого вопроса - что делатьмы имеем ввиду время?Когда пользователь говорит, что хочет что-то запустить в 7:00, что они имеют в виду?В большинстве случаев они имеют в виду 7:00 утра, где они находятся - но не всегда.В некоторых случаях, для точного сравнения, скажем, статистики веб-сервера, они хотят, чтобы каждый «день» заканчивался в одно и то же время, без корректировки на летнее время.С другой стороны, кто-то, кто принимает лекарства в определенное время дня и имеет это в своем календаре, захочет, чтобы это всегда происходило по местному времени, поэтому событие в 15:00 не в 3:00, когда они путешествуют на полпути.мир.
Итак, у нас есть три основных варианта использования (есть и другие, но они обычно могут обрабатываться следующим образом):
1. Тот же абсолют (из-за отсутствия лучшего слова)время.
2. Время в данном часовом поясе, смещение при включении / выключении летнего времени (включая двойное летнее время, которое происходит в некоторых регионах).
3. Местное время.
Первое тривиально для обработки - вы устанавливаете его как UTC.Делая это каждый день года будет иметь 24 часа.(Интересно отметить, что UTC соответствует времени в Гринвиче только в течение стандартного времени. Когда это летнее время, Гринвич и UTC не идентичны.)
Для секунды требуется сохранение времени и часового пояса.Однако часовой пояс - это географическая зона, а не текущее смещение (смещение - это разница с UTC).Другими словами, вы храните «Горное время», а не «Горное стандартное время» или «Горное летнее время».Так что 7:00 утра в «Горное время» будет 7:00 утра в Колорадо, независимо от времени года.
Третий аналогичен второму в том, что у него есть часовой пояс, называемый «Местное время».Однако, это требует знания, в каком часовом поясе он находится, чтобы определить, когда это происходит.
В Outlook теперь есть средства для этого.Нажмите кнопку часовых поясов:
И теперь вы можете установить часовой пояс для каждого события:
Когда у меня есть командировки, я использую это, включая время вылета в одной зоне и прибытия в другую.,Outlook отображает все в местном часовом поясе и корректирует, когда это меняется.С другой стороны, iPhone не подозревает, что это происходит, и отключает все, когда я нахожусь в поездке, которая находится в другом часовом поясе (а когда вы живете в Колорадо, почти каждая поездка происходит в другом часовом поясе).
Использование его
Хорошо, как вы справляетесь с этим?Это на самом деле довольно просто.Каждый раз необходимо хранить один из двух способов:
1. Как по Гринвичу.Обычно при сохранении в формате UTC вы все равно будете устанавливать / отображать его по местному времени.
2.В качестве даты и времени плюс географический часовой пояс (который может быть «местным временем»).
Теперьхитрость заключается в том, чтобы знать, что использовать.Вот некоторые общие правила.Вы должны будете выяснить это для дополнительных случаев использования, но большинство из них подпадают под эти категории.
1.Когда что-то случилось - UTC.Это единичное событие, и независимо от того, как пользователь хочет, чтобы оно отображалось, его нельзя изменить.
2. Когда пользователь выбирает часовой пояс UTC - UTC.
3.Anсобытие в будущем, когда пользователь хочет, чтобы это произошло в часовом поясе - дата и время плюс часовой пояс. Теперь может быть безопасно использовать UTC, если это произойдет в течение следующих нескольких месяцев (изменение часовых поясов, как правило, вызывает такое большое предупреждение - хотя иногда это всего лишь 8 дней), но в какой-то момент вам нужно это сделать, поэтому вы должны это сделать для всех случаев. В этом случае вы отображаете то, что вы сохранили.
4. Для запланированного события, когда это произойдет в следующий раз - UTC. Это требование к производительности, при котором вы хотите иметь возможность получать все «следующие события» там, где их среда выполнения была раньше. Гораздо быстрее искать по датам, чем пересчитывать каждую. Однако для этого необходимо регулярно пересчитывать все запланированные события в случае изменения правил для события, которое проводится каждый квартал.
1.Для событий, которые относятся к «местному времени», пересчет должен происходить при каждом изменении часового пояса пользователя. И если в изменении пропущено событие, оно должно произойти немедленно.
.NET DateTime
Погружаясь в .NET, это означает, что мы должны иметь возможность получить две вещи, которые стандартная библиотека не предоставляет:
1.Создайте DateTime в любом часовом поясе (DateTime поддерживает только ваш местный часовой пояс и UTC).
2.Для заданной даты, времени и географического часового пояса получите время UTC. Это должно быть скорректировано на основе правил DST для этой зоны на эту дату.
К счастью, есть решение для этого. У нас есть открытые расширения функциональности часового пояса DateTime. Вы можете скачать WindwardTimeZone здесь. При этом используются параметры реестра в Windows для выполнения всех расчетов для каждой зоны, и поэтому они должны оставаться актуальными.
Боль в браузере
Одна вещь, которую мы не выяснили, - это как узнать местоположение пользователя, если он использует браузер для доступа к нашему веб-приложению. Для большинства стран локаль может использоваться для определения часового пояса, но не для США (6 зон), Канады или России (11 зон). Таким образом, вы должны попросить пользователя установить его часовой пояс - и изменить его, когда он путешествует. Если кто-нибудь знает решение этой проблемы, пожалуйста, дайте мне знать.
Обновление: Я получил следующее от Джастина Боннара (спасибо):
document.getElementById ('timezone_offset'). value = new Date (). getTimezoneOffset ();
Использование этого плюс предложение географического местоположения для IP-адреса, упомянутого ниже, приблизит вас. Но это не 100%. Смещение по времени не говорит вам, например, если вы находитесь в Аризоне (они и Гавайи не наблюдают за переходом на летнее время) в сравнении с часовым поясом Тихого / Горного (в зависимости от летнего времени). Вы также зависите от того, включен ли javascript, хотя это верно для 99% пользователей сегодня.
Географическое положение на основе IP-адреса также сомнительно. Я был в отеле в округе Колумбия, когда получил сообщение о проблеме с нашей формой загрузки демо. Мы предварительно заполняем форму с указанием города, штата и страны в зависимости от географического положения IP-адреса. Он сказал, что я был в Кливленде, штат Огайо. Итак, снова, как правило, верно, но не всегда.
Я полагаю, что мы можем использовать смещение, и для случаев, когда есть несколько часовых поясов с этим смещением (в данный день), свяжемся с гео IP-адресом. Но я уверен, что желающие могут добавить tz = к информации заголовка, отправленной с запросом HTML.