временная метка и запланированные пост -неровности

Question

Обновление: я подтвердил проблему (что запланированные сообщения основаны на времени UTC), теперь просто нужны советы и фон, чтобы определить лучшее решение. Вопросы:
1) Как WP определяет время UTC, прежде чем вычислять локальное смещение часового пояса (т.е. использует ли он время Серверной ОС или какой-либо другой источник-нельзя найти в Codex/Googling)
.. что поможет мне ответить ..

2) Является ли изменение времени сервера с UTC на локальный PST единственный/лучший способ сделать запланированные сообщения использовать тот же часовой пояс, что и WP-Time? а также
2А) Существуют ли потенциальные негативные последствия для изменения времени сервера с UTC на локальный?
3) Как лучше всего изменить время сервера точным образом-когда я устанавливаю часы, это не должно быть точно правильным, но я буду беспокоиться о том, чтобы вручную установить время на сервере.

Всем привет-

Проблема: Во -первых, WP начал пропустить публикацию запланированных сообщений. Это, кажется, является проблемой с широко распространенной проблемой, и я исправил ее, используя плагин «пропущенный график». Это, вероятно, но не обязательно, не относящийся к делу.

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

Стек: LNMP, One Nginx Box, One DB/MEMCACHE/PHP Box (хотя я не мог и не мог его создать)

Насколько я знаю, в нашем стеке есть 4 места, где время установлено/полагается: в общих настройках WordPress (установлено в PST, но также правильно отображает время UTC Server), для PHP5 в php.ini (был установлен на центральный Время, где новый сервер, но я обновил PST и перезапущенную PHP-FPM, как только я понял, что у PHP5 есть настройка часового пояса, уменьшая расхождение на 2 часа), и в каждой коробке (оба установлены время UTC, которое я был Предполагается, что это нормально, потому что WP распознает его как таковую, как может установить свое «собственное» время).

Тем не менее, я сейчас смотрю что -то, что не должно быть возможно. Был назначен пост в 9:30 утра, но вместо этого опубликовано в 1:30 по тихоокеанскому времени (9:30 утра UTC). Это привело к тому, что «опубликованная x назад» относительная метка времени на посту считал задом наперед с 8 часов, а затем снова начнула рассчитывать в 9:30 утра. Для меня это означает, что, хотя пост -планировщик (казалось бы,) должен рассматривать (правильно настроено) локальное время WP (как и фронт), вместо этого он использует UTC (сервер).

Параметры решения:
A. Пересмотрите ОС в обоих коробках, плюс PHP, плюс все блоги WP, чтобы использовать только время UTC, и инструктируйте всю редакционную статью жить в UTC.
B. Пересмотрите ОС обеих коробок в PST, чтобы соответствовать PHP и WP. Похоже, что это, вероятно, решение (с тех пор, как пост опубликован на сервере/UTC Time), но я *nix n00b и просто хочу убедиться, что я должен использовать «дату -с» и просто попытаться быть максимально точным, Или, если бы было умнее просто оставить билет на поддержку хоста, прося их синхронизировать время оба сервера с PST? (Или, если есть лучший способ быть точным)

Чего я не понимаю:
A. Почему пост -планировщик игнорирует «время WP», чтобы сделать расчет о том, когда публиковать? (Обновление: я думаю, что ответ здесь: http://codex.wordpress.org/function_reference/wp_schedule_event - Он анализирует время с помощью временной метки Unix напрямую, а не через WP?)
B. Зачем даже настройки WP, отделяющие время UTC от локального времени, если все функции не рассчитывают время из одного и того же источника?

Почему это проблема:
У нас есть 15 сайтов, с основными пользователями сайта в разных часовых поясах. В идеале они могут установить WP «локальное время» в блоге, и все пост -планирование и функции полагаются на это указанное время. Если планирование основано на времени сервера, это кажется невозможным.

Answer 1

Для начала попробуйте Контроль ядра плагин, чтобы увидеть, точно ли назначены запланированные задачи. Запланированные сообщения будут отображаться как publish_future_post > check_and_publish_future_post() с идентификатором поста в качестве аргумента.