Алексей Уколов

Это легко делается при помощи расширений в браузере.
Да только, скорее всего, не поможет это тебе - либо найдёшь что-то другое на что можно отвлечься, либо снимешь блокировку, найдя какую-нибудь причину, чтобы оправдаться перед самим собой.

Если тебя беспокоит твоя прокрастинация - нужно искать причину и решать её, а не следствия (залипание на ютубе - это как раз следствие)
Разные возможные причины, способы поиска своих, и возможные варианты решения хорошо разбирает Максим Дорофеев в своих докладах и книгах.

Учи азы программирования.
Exit code 0 в практически любой операционной системе означает, что программа завершилась без ошибок. Это относится и к программам на питоне - они завершаются с кодом 0, если выполнение спокойно дошло до конца файла без непойманных исключений. Есть ещё функция sys.exit(), но про неё сам почитаешь.

А в твоём случае ты накосячил в обёртке тела программы. Правильно будет
if __name__ == "__main__":
Тоже советую погуглить и почитать, что это, как работает, и зачем оно.

Никак. Переменную среды (мы же про линух говорим, да?) можно задать чертовой прорвой разных способов, причем зависящих от дистрибутива.

Кину 5 копеек по поводу работы с датами. Да это зло. Работа с датами в современном API это
самый большой технический долг начиная с Unix, когда дата представлялась секундами с 1970 года
в виде DWORD. Я не встречал ни одного языка программирования и ни одной DBMS где изначально
была-бы какая-то очень строгая и математичная концепция работы с временем. Везде были ограничители
в основном завязанные на примитивные типы либо на строки вариативной длины. В Java например
долгое время экплуатировался тип java.util.Date который сегодня считается дыркой (мутабельность)
и неточным и его заменяют на java.time.* семейство типов. Параллельно с ним где-то в космосе
висит java.sql.Date который декларирован в интерфейсах JDBC как основа для БД. С ним-же и работают
все драйвера реляционных бд.

По поводу вычислений на application tier. В последнее время DBMS девальвировали. И в основном
используются в микросервисах как хранилище таблиц без особой логики. В этом есть свои смыслы.
Например удобнее тестировать и хранить 100% кода в языках Java/Node/C#. Это создает гомогенность
языка в проекте. В противном случае логику пришлось бы неизбежно резать на 2 слоя и хранить
половину в application и другую половину деплоить через flyway/liquibase в БД при этом еще и
не забыть тестировать 100% совместимость тех-же функций для работы дат-времени (никто
кстати невкурсе что в Oracle год может быть 9999 а java.util.Date мне удалось сгенерировать
такую Aug 17 09:12:55 EET 292 278 994. .. оптимистичненько доживем до 290 миллионов
лет хотя проблема comparison этих типов остается) Стандарты ISO помогают но они скорее
декларируют намерения сохранить нужное значение. Вот и если вы новичек - то я гарантирую
что вы словите кайф в попытке в Java разобраться в проекте какой тип дат вам брать. И еще
помножите это все на типы данных БД (их там будет 4 штуки обычно. Парочка для зональных
и парочка для локальных).

Использовать или нет функции PG? Ответ - it depends. В некоторых случаях оптимизатор не видит
индекса если ты делаешь неявный кастинг из строки в дату например. Я тут не уверен надо проверять.
Но есть старая админская поговорка. Плохой execution plan - проверь типы данных в предикатах.
Беда реально существует для Spark/Databricks и даже включена в учебный план. По крайней мере int/Long
различается на уровне Catalyst-optimizer. Вобщем если вы - лентяй то можете лупить строки вместо дат
и надеятся что SQL машина правильно интерпретирует. Если вы хотите быть точным то делайте CAST или
to_date с явным описаловом YYYY-MM и т.д.

Еще один поинт в части где хранить логику. Это я пишу просто для кругозора. Чтобы топик
не циклился вокруг Постгреса а люди видели пошире. В классических БД данные качаются
к клиенту. Тоесть делаете SELECT * из миллирад строк - и этот миллиард будет прокачан до конца
когда вы читаете резалт-сет по сети. Такова парадигма. Или курсор. Но суть таже. А в BigData данные
лежат на месте но к ним "ходит" код. Вот такой метафизический парадокс. Сами понимаете что
тут получается что встроенных функций даже как бы ... и нет. Подчеркиваю разницу.

пп. 4 и 5 конфликтуют друг с другом. Потому что приложение - тем более под iOS - должен кто-то написать :)

Критерии "простой" и "интуитивно понятный" - качественные и зависят от сообразительности и интуиции пользователя. Из трекеров техподдержки (с очередями, заявками и исполнителями) можно попробовать OTRS.

Перейти на джаву вполне реально, имея какой-то опыт на php. Я так делал. У меня были небольшие пет-проекты на Java.
Есть одно существенное препятствие - джава требует компиляции, в отличие от php, к тому же большое джавовское приложение может подниматься несколько минут. Использование hot reload не дает того удобства, которое есть в php. Если вы привыкли быстро видеть результат, то придется переучиваться. Стараться продумывать глубже свой код, а не кодить по принципу: попробую так, а вдруг заработает.

PHP я крайне не рекомендую в качестве первой работы. Слишком много плохих контор, использующих пхп.
Если вы попадете в такую, у вас будет только единственное желание - побыстрее свалить.

Да, но не на джунской вакансии.

Сам по себе современный пых как раз очень сильно покусан явой.
И если писать на пхп, используя современные подходы в ООП, то при переходе на яву увидишь очень много общего. Собственно, пхпшники всю жизнь учили паттерны проектирования по книжкам для Явы.

Но сдается мне, что под "вакансиями пхп в моем городе" подразумеваются исключительно битрикс и вордпресс. Которые не то что ничего не прибавят к опыту, а наоборот, дадут только жирный минус.

Но сначала надо научиться формулировать вопросы. Без этого умения ни в пхп ни в яве толку не будет