Місцеві часові пояси на серверах вважаються шкідливими? [зачинено]

Мені цікаво, яким є досвід інших адміністраторів із часовими поясами, в контексті віддалених серверів. У своїй кар’єрі я натрапив на кілька конвенцій;

1. Завжди, завжди, завжди використовуйте UTC.
2. Завжди, завжди, завжди використовуйте часовий пояс, де б не було базове штаб-квартира.
3. Використовуйте місцевий час людей, які випадково проводять управління.
4. Використовуйте місцевий час розташування сервера.

У деяких місцях я натрапив на численні та суперечливі умови. Моє власне вподобання було використовувати UTC, завжди - без економії денного світла. Але з тієї чи іншої причини, здається, більшість людей вважають за краще використовувати якусь концепцію місцевого часу, з економією денного світла. Хоча це здається прямим технічним питанням, дискусії навколо змін конвенцій завжди здаються тенденцією до релігійних розколів.

Що ви використовуєте? Які ви вважаєте переваги та недоліки кожного підходу?

• Годинник обладнання завжди повинен бути UTC. Завжди.
• Часовий пояс як налаштування може бути будь-яким зручним. Зазвичай. Іноді це також має бути UTC.

Деякі причини, чому UTC приємно:

• Правила літньої економії змінюються, і оновлення не завжди відбуваються вчасно. UTC змушує це піти.
• Коли потрібно порівнювати журнали із серверів у різних місцях, UTC робить чудовим загальним стандартом.
• Зазвичай, коли сервери знаходяться в різних місцях, люди або програми або обидва повинні мати справу з перетвореннями часу під час виконання, скажімо, вставок бази даних. Якщо у вас є одне перетворення (на UTC), то це набагато простіше отримати право, ніж якщо ви повинні перетворити з одного TZ в інший, залежно від сервера, TZ.

Я вважаю за краще варіант 4. Потрібно, щоб програми, що працюють на сервері, вирішили, зберігати значення DateTime у UTC чи ні.

Крім того, коли сервер записує журнали системних подій, приємно мати можливість співвіднести локальні події з записами журналу. Наприклад, якщо центр обробки даних повідомляє про порушення мережі в місцевий час, ви можете легко визначити будь-які проблеми, що виникли, не перетворюючи значення часу в голові.

Ні, ні, тисячу разів ні.

Є два типи програмістів ... Ті , хто розуміє , що МестноеВремя повинні використовуватися для відображення / цілей форматування тільки , і ті , які малюють себе в кут ... і вони малюють з гасом .

Усі події слід записувати в UTC, а результати перетворювати на місцевий час лише для відображення їх користувачам. Прокляті - це ті, хто цього не робить, а подвійні - це ті, хто використовує локальний час у форматі, який відкидає інформацію про часовий пояс (я дивлюся на вас , Oracle DBA).

Подумайте про це як про перевірку непорушності ... Якщо ви перетворите часовий вимір у локальний час і потім зробите все, що не випускає його в STDOUT, ваша програма повинна не тільки вийти зі смертельною помилкою, але й видалити джерело, щоб навчити вам урок.

Коли мені надано вибір, я люблю тримати годинник BIOS на UTC, але фактичний час сервера як локальний час. У нас немає присутності в багато часових поясах, тому уніфікована мітка часу журналу не є проблемою, яка була б, наприклад, для 3M.

У моїй компанії у нас були всі сервери в одному ТЗ до цього року. Зараз у нас є сервери в 3 нових часових поясах. Весь сервер працює з нашим місцевим часовим поясом. Це досить корисно для аналізу журналів , тим більше, що ми розповсюджували веб-сайти, що працюють у трьох часових поясах.

Однак в одному спеціальному випадку ми залишили сервер із нашим клієнтом TZ. Програма повинна працювати в більшій частині дня, і завдання технічного обслуговування, як правило, налаштовані на виконання протягом "ночі". Спочатку ми встановили сервер у нашому TZ, але завдання з технічного обслуговування були занадто уповільнені для наших улюблених "ми працюємо, коли ви спите" клієнтів ...

UTC також дуже приємний варіант. Якщо люди завжди не звертаються до місцевого часового поясу, коли дивляться на журнали (що тут є).

Я запускаю всі свої сервери в UTC, і перетворюю будь-які, які потрапляють під моє управління, як тільки я можу.

Досі єдиним винятком був сервер зірочок, який мені довелося залишити за місцевим часом. Змінивши його на UTC, повністю зірвалася зірочка. (На 1.6, сподіваємось, це не буде проблемою, коли я збираюся модернізувати його пізніше цього року.)