N

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

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

можно конечно.
но хорошая практика - иметь единственное место вывода.

$dateTime = new DateTime('2021-05-18T15:30:00.000-04:00');
var_dump($dateTime);
$dateTime->setTimezone(new DateTimeZone('Europe/Moscow'));
var_dump($dateTime);

// object(DateTime)#1 (3) {
//   ["date"] => string(26) "2021-05-18 15:30:00.000000"
//   ["timezone_type"] => int(1)
//   ["timezone"] => string(6) "-04:00"
// }
//object(DateTime)#1 (3) {
//  ["date"] => string(26) "2021-05-18 22:30:00.000000"
//  ["timezone_type"] => int(3)
//  ["timezone"] => string(13) "Europe/Moscow"
//}

$timestamp = strtotime('2021-05-18T15:30:00.000-04:00');
var_dump($timestamp); // int(1621366200)
date_default_timezone_set('Europe/Moscow');
$dateTime = date('c', $timestamp);
var_dump($dateTime); // string(25) "2021-05-18T22:30:00+03:00"

разница в том что это совершенно разные проекты, общее между ними только html
все остально еразное
apache старый
nginx поновее и в нем меньше обратной совместимости да и собран он уже со знанием что есть биг дата и тд.
В общем он посвежее и побыстрее работать будет
В nginx php интерпретируется сторонним демоном, это как правило php-fpm
В апчье есть mod_apache - являсь модулем апача он работает быстрей лучше получает коды завершения и тд, но слишком сатрый и плохо параллелится маштабируется и с правами там трабылы, НО он самый частый до сих пор.
Есть и дургие представления пхп FastCGI CGI PHP-FPM и тд. в общем для апача есть все
nginx в свою очередь молодой и не все на нем работает сразу, поскольку большенство движков cms созданы под апачь, и требуется переписать htccess на правила nginx.

nginx часто используют в связке с апачем как прокси сервер.
статику отдает nginx динамику апач.
так же nginx отлично балансирует бэк сервера в такой конфигурации да и собственный upstream есть , в общем при большом количестве серверов с ним лучше работать.
ну есть nginx+ даже облачный есть.

для изучения поставь связку nginx+apache+php-fpm
это достаточно современная связка и заодно выучишь и то и то.
А еще лучше поставь что-то вроде vestacp с таим расширение тут уже будет все нормально настроено и можно будет смело приходить к стадии изучения.

function getTimes(start, end, interval) {
  const [ s, e ] = [ start, end ].map(n => moment(n, 'HH:mm'));
  const result = [];

  if (s > e) {
    e.add(1, 'day');
  }

  for (; s <= e; s.add(interval, 'minutes')) {
    result.push(s.format('HH:mm'));
  }

  return result;
}

или, без moment.js (разница невелика, сами видите):

function getTimes(start, end, interval) {
  const [ s, e ] = [ start, end ].map(n => new Date(`2000-01-01 ${n}`));
  const result = [];

  if (s > e) {
    e.setDate(e.getDate() + 1);
  }

  for (; s <= e; s.setMinutes(s.getMinutes() + interval)) {
    result.push(s.toTimeString().split(':', 2).join(':'));
    // или
    result.push(s.toLocaleTimeString('ru', {
      hour: '2-digit',
      minute: '2-digit',
    }));
  }

  return result;
}

использовать, понятное дело, так: const times = getTimes('10:00', '18:00', 30);.

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

я бы пошел и поработал год или несколько:
1. может и не отстой: с теми же CMS можно работать совершенно по-разному.
2. уже будет опыт, которым можно козырять.

https://yandex.ru/search/?text=php%20Очистка%20POST
https://www.cyberforum.ru/php-beginners/thread1697...

Как сказал коллега выше - преждевременная оптимизация - корень всех зол. Вопрос не в языке и не в фреймворке. Каждый из современных языков и фреймворков можно оптимизировать. Возьмите то, с чем вы будете испытывать меньше трудностей. Можно ведь пилить бесконечно идеальный продукт, и никогда его не выпустить. Fail fast, fail cheap.
Оптимизацией лучше заниматься тогда, когда возникает в этом необходимость и там, где возникнет эта необходимость. Пилить сразу большой проект на чистом GO, я думаю будет очень сложно человеку, не знакомому с языком, и возможно не знакомому с инфраструктурой микросервисов. Go это ведь не только синтаксис. Да и даже в больших проектах на GO выносят только отдельные микросервисы, требующие оптимизации. (*так по крайней мере было на моей практике).
за 8к вы точно не найдете достаточно программистов чтобы пилить приложение на go-микросервисах, k8s эксперта который правильно будет деплоить и поддерживать k8s инфраструктуру вместе с ci-cd. А если всем заниматься самому, то хорошего из этого ничего не выйдет, глаз начнет дергаться.

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

но опасаемся, что Laravel будет работать очень медленно в случае такой посещаемости.

А вдруг не будет такой посещаемости?
Я б выбрал laravel, потому что преждевременная оптимизация — корень всех зол.

Правы оба.
Лучше раньше упасть, чем обработать кривые данные так, как будто они нормальные. Но и просто бездумно падать в самую базовую ошибку неправильно - потом задолбаетесь выяснять при каких обстоятельствах код упал. Лучше провалидировать и кинуть осмысленное исключение, которое поможет отловить проблему.

https://laravel.com/docs/8.x/validation#validating...

Есть целая наука об этом. "Временные ряды", вроде, называется. Там есть куча всяких моделей, типа ARIMA.

да перестаньте уже насиловать мозг регулярками там, где они не нужны.
любой XML (и HTML в частности) давно отлично разбирается и обрабатывается стандартными средствами.
dom parser и xpath к вашим услугам.