Это может не иметь большого значения для небольших магазинов, у которых есть только один или несколько сайтов, но для крупных организаций это то, что меня интересует.
Какие плюсы и минусы у всего / большей части вашего сервера в UTC? Это, безусловно, поможет в отчетности и централизованном ведении журнала. Также с корреляцией событий для устранения неполадок или аудита безопасности. Также не пришлось бы так беспокоиться об изменении летнего времени.
Одним из недостатков может быть то, что планирование автоматических событий (например, cron) может занять некоторое время, если вы хотите, чтобы он запускал что-то в «4 часа ночи» по местному, географическому времени. Для Unix-y у вас все еще могут быть пользователи в локальном часовом поясе, установив «TZ» в / etc / profile, но для пользователей Windows, которые подключили RDesktop к серверу (по какой-либо причине), они застряли в просмотре UTC?
Как и в большинстве случаев, «это зависит от обстоятельств».
Я выбрал все параметры (местное, UTC, произвольно, но согласованно) и предпочитаю «местное время для домашнего офиса для всех машин», поскольку именно там были системные администраторы и пользователи, хотя машины были разбросаны по всему миру. .
Мы устанавливаем все на GMT, это упрощает сопоставление файлов журналов между системами.
Но я считаю, что нам следует отказаться от часовых поясов и использовать GMT для всего.
Как говорили другие, это зависит от обстоятельств. Приняла участие очень большая группа с длительным и обширным опытом в этом вопросе. Группа состоит из вооруженных сил по всему миру, и они используют UTC (GMT).
Еще одна вещь, которую следует учитывать. Если эти системы поддерживают код приложения, вы должны знать, знают ли приложения часовой пояс. На некоторых форумах по программированию, в которых я участвую, я предлагаю всегда хранить дату / время в базе данных в формате UTC и давать конечному пользователю возможность видеть дату / время.
Я работаю в очень крупной хостинговой компании, и у нас есть центры обработки данных по всему миру. Обычно мы устанавливаем машинное время на время локального центра обработки данных, а затем используем часовой пояс, в котором находится весь наш обслуживающий персонал, как универсальное время, в которое преобразуются вещи при использовании инструментов и т. Д.
Как говорили другие, нет единого правильного ответа, но мы используем этот метод :)
Политика здесь гласит, что все машины привязаны к своему местному часовому поясу (то есть физическому местоположению). Единственное, что сложно - это сопоставить записи журнала событий (Windows Machiens), поскольку время указано как nlocal - большинство других файлов журнала все равно записывают время в формате UTC.
но для пользователей Windows, которые подключили RDesktop к серверу (по какой-либо причине), они застряли в просмотре UTC?
Не совсем уверен, но я думаю, что да - часовой пояс логически является настройкой на уровне машины.
У нас есть машины, физически расположенные в одном часовом поясе, которые установлены на 3 часа вперед из-за приложения, которое они поддерживают.
У нас также есть разработчики, которые создают программное обеспечение, рассчитывающее на синхронизацию между серверами менее пяти секунд, разработчики, которые неявно полагаются на время AD для синхронизации и которые не утруждают себя написанием процедур проверки ошибок или обработки для несинхронизируемых случаев, и которые утверждают что последующие сбои - это вина администраторов, которые не поддерживали время в сети в соответствии со стандартом, который они себе представляли.
Не делай того, что мы сделали. Это только вызовет горечь.
Чтобы добавить к обсуждению, у нас есть офисы, разбросанные по всему миру, и каждый из них имеет свой собственный набор веб-серверов, серверов приложений и баз данных, с различными ветвями приложений для каждого из них, поэтому местный часовой пояс - хорошая идея, пока говоря по всей стране. Для серверов в США мы движемся к центральному времени для всех мест, чтобы соответствовать нашему основному центру обработки данных, поскольку использование разных часовых поясов для серверов приложений и баз данных доставляет разработчикам трудности.
Приложение Yeller недавно опубликовало Сообщение блога советовать всем системным администраторам использовать UTC. Вот отрывок:
Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC.
Помимо шуток, в основном говорится, что использование только UTC означает не беспокоиться о переходе на летнее время (DST) и ошибках, которые это вызывает.