владивосток и +10: как приучил себя не путать время сервера с местным

Второй день осваиваюсь, спасибо, что тепло встретили. Бытовая мелочь, на которой я уже спотыкался и, чувствую, не только я: у меня +10, сервер по времени в UTC, и я постоянно путался — cron поставил «на 9 утра», а он сработал глубокой ночью по-моему.
Приучил себя: на сервере держу UTC (не трогаю), а всё, что «по утрам», считаю с поправкой на свой +10, и в cron пишу уже пересчитанное. Плюс в логах всегда смотрю на таймзону, а не на цифру. Кто далеко от Москвы — вы серверу свой пояс ставите или живёте в UTC и пересчитываете? Особенно интересно, как с этим те, у кого клиенты в разных поясах.

vlad_dv о, а я про это даже не думал, у меня +7 и сервер тоже в UTC, но я cron почти не трогаю)) один раз бэкап не в то время сработал, я не понял почему, теперь ясно — таймзона. спасибо, что написал, а то я бы опять час гадал. держись, восточных прибавляется, скоро москвичей перевесим по духу))

vlad_dv я на UTC живу и пересчитываю, как ты — меньше сюрпризов, чем когда сервер в местном, а логи внешних сервисов в UTC, и ты гадаешь, что с чем сравнивать. Единственное, для отчётов клиенту ставлю вывод в его пояс, но это уже в приложении, не на уровне сервера. +7 привет +10, у нас тут своя лига по ту сторону Урала)

vlad_dv правильный подход: сервер в UTC, а «по утрам» пересчитывать. добавлю граблю: если ставишь TZ на сервере в свой пояс — потом логи внешних сервисов (в UTC) не сходятся с системными, и при разборе инцидента гадаешь. держи UTC везде, а человеческий вывод — в приложении. cron с UTC привыкаешь читать за неделю.

vlad_dv ещё лайфхак: в cron можно писать CRON_TZ=Asia/Vladivostok прямо в crontab, тогда расписание задаёшь в своём поясе, а система остаётся в UTC. Работает не везде — в busybox cron и некоторых минимальных образах этой переменной нет, так что проверь на своём: поставь задачу на минуту вперёд и посмотри, сработала ли. Если нет — пересчитывай руками, как сейчас.

ivan_tver про CRON_TZ полезно, но есть ещё тонкость: при переводе часов в некоторых поясах задача может сработать дважды или ни разу. Для +10 это неактуально, но если клиенты в Европе или США — лучше держать критичные задачи в UTC и не полагаться на CRON_TZ. Проверить просто: залогировать date в начале скрипта и сравнить с ожидаемым временем запуска.

kirill_nsk так у тебя бэкап хотя бы сработал, просто в другой день. я с cron в utc вообще в разных сутках живу, встречаемся только в логах)

void_3am «встречаемся только в логах» это прямо в десятку))

я когда первый раз увидел что бэкап «сделался завтра», чуть не полез искать кто сервер сломал. сижу поздно вечером, смотрю — время в логе на семь часов впереди моего, думаю всё приехали, кто-то часы перевёл. а это просто utc стоит и всё. я сам себя напугал, даже искать некого было.

теперь я себе на телефоне вторые часы поставил с utc. выглядит как у параноика, зато когда в wg show вижу latest handshake я хоть понимаю относительно какого времени он latest, а не гадаю опять.

а ты cron под что-то серьёзное гоняешь? у меня там бэкап и всё, может я его зря боюсь

ivan_tver проверил после ужина: добавил в crontab CRON_TZ=Asia/Vladivostok и задачу на минуту вперёд — сработала ровно в моё время, Ubuntu переменную понимает. Но пересчитывать в уме всё равно не брошу, и date в начало скрипта уже добавил, как выше советовали: теперь в логе видно и пояс, и факт запуска, а не просто «вроде отработало».

kirill_nsk писал:
теперь я себе на телефоне вторые часы поставил с utc. выглядит как у параноика

не параноик, а человек с сервером) у меня вторые часы на панели давно висят. а веселит меня другое: мой «утренний» бэкап на 9:00 по моему времени — это вчерашние 23:00 по серверному. первый раз увидел в логе свежий бэкап с вчерашней датой, полез проверять, не пропустил ли сутки. не пропустил — просто живу в будущем относительно собственного сервера.

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

kirill_nsk серьёзное это не про меня. у меня cron бэкапит папку с мемами. однажды не сработал — вот это была паника, не то что у тебя)

kirill_nsk wg handshake в utc это отдельный вид спорта. я по нему однажды решил что телефон умер, а он просто жил во вчера)

vlad_dv «человек с сервером» звучит гордо, возьму. а то параноик с двумя часами меня уже честно не устраивал))

а файлы бэкапов у тебя как называются, по серверной дате или по твоей? у меня ночной бэкап в три часа это 20:00 по utc, то есть ещё вчера, и файл лежит с вчерашней датой. каждое утро глазами ищу сегодняшний и не нахожу, два раза уже думал что не отработал ((

void_3am мемы это критичные данные, я б тоже паниковал

kirill_nsk, у меня архив мемов тоже по серверной дате. файл свежий, а на имени вчерашнее число.
сами мемы старше обоих часовых поясов)

kirill_nsk, за «критичные данные» спасибо. папка с мемами впервые получила уважение)
осталось назвать архив backup_final.tar и перестать смотреть на даты. хотя слово final нас уже много раз подводило

kirill_nsk, пять утра. мы тут всю ночь обсуждаем, как бэкап сделать вовремя, а лечь вовремя никто так и не смог)

void_3am, слово final мне уже нельзя использовать. есть backup_final, backup_final2 и backup_точно_финал — по названиям все три главные))

дату всё-таки оставлю, только прямо допишу utc. а то два часа на телефоне завёл, а архив всё равно ищу по своим. вчерашний файл никуда не пропадал, это я утром смотрю мимо.

kirill_nsk, «точно_финал» это диагноз. у меня был new_v2_рабочий — он не был. теперь называю архивы датой и молюсь, вранья в имени хотя бы меньше)