Comments 4
часовые пояса и региональные локали
бро, даже до семечек не дошел. это очень сильная проблема. знакомый в Auslogics планировщик делал, ох как там все сложно.
Согласен, тут ещё просто. У нас пояс один (Ташкент, +05 без DST), поэтому вся боль свелась к границе суток и фолбэку на фиксированное смещение. Планировщик с повторяющимися событиями через DST-переходы - это мрак, на одной из прошлых работ похожие проблемы решал, там и «время, которого не существует» при переводе стрелок, и «9 утра по чьему времени» при переезде пользователя. Как раз поэтому я намеренно не стал строить свой шедулер, а напоминания считаем в одном фиксированном поясе фермы. Если знакомый рассказывал детали про Auslogics - с удовольствием почитал бы в виде статьи :)
История из другого проекта
Еще стартап один веду - blinking-box, реклама в Узб. на курьерах. Там со временем были шарады. Из-за того что не ясно в каком времени показывать отчеты, геометки и прочее по показанной рекламе - все превращалось в сумбур. Допусти ситуация: заказчик из США хочет рекламу с 9:00 до 12:00, вот и проблема: в каком времени рекламу эту показывать и какое время им в отчеты вставлять, учитывая что все участники еще разбросаны по разным часовым поясам (головной офис в одном, представитель в другом, пользователь в третьем, ну и т.д.). Решили проблему в итоге на чисто бизнес-уровне, дороговорились на UTC, через UI универсального и главное удобного решения не нашлось. Поэтому да, тема времени очень глубокая.
2. Настоящий Postgres на деве, который гарантированно умирает вместе с процессом
Добротный вы костылище написали, конечно.
Обратите внимание на Aspire. Подключаете зависимости - райнтайм запустит их в контейнерах и потом гарантированно прибьёт. Да, нужен docker desktop, но ничего не висит на фоне и не занимает порты.
Зачем:
dev работает как production, не нужно бояться, что где-то выстрелит неочевидная разница между, например, linux и windows
вот у вас postgres и вы написали для него debug-only костыль с распаковкой бинарников, job object и кто знает ещё чем. А если завтра понадобится redis? или temporal?
6. Тихие баги нормализации: часовые пояса и региональные локали
Фолбэк на «жёсткое +5» здесь осознанный: узбекский часовой пояс не знает перехода на летнее время, поэтому даже если на сервере урезанная tz-база (бывает в минимальных Linux-образах) и
Asia/Tashkentне резолвится по имени, фиксированное смещение остаётся корректным всегда, а не только «пока не наступит переход на летнее время».
Вы же контролируете серверное окружение? Вы можете гарантировать своему приложению наличие tzdata, тогда никакие фолбэки не будут нужны.
Интересно, не знал о таком. Замечания хорошие, учту. Но я больше .NET программист чем DevOps или системник, поэтому пошел по тому пути, где имею наибольшую компетенцию :)
Но справедливости ради - это не продакшен крупной компании, это мой "домашний проект", и мне намного проще сделать так чтобы приложение работало в разных условиях, чем разные условия готовить под приложение.
В идеале конечно было бы сделать небольшого отдельного юзера на локальной машине, разделить домены по отдельным проектам, с аккуратными sitemap и прочим, в проде взять линукс, настроить все порты, вынести БД на отдельный сервер без внешних дыр, ну и так далее, но если делать это все в одиночку - скорее раньше выгоришь чем добьешься MVP.
Но вы правы что с Postgres я накостылил, но у меня ситуация такая, что я параллельно использую другие виртуальные окружения, из-за чего виртуализация докера, а точнее фичи виндовс которые он требует - конфликтуют с теми, что я использую в других проектах, и в выборе накостылить postgres или другие проекты, для личного удобства разработки, я выбрал пустить под нож докер :)
Овцеводческая CRM, Узбекистан и .NET 10: семь инженерных историй с граблями