Flying

Поскольку вы наследуете свой класс от абстрактного класса - иницализация parent'а - ваша прямая обязанность (см. сноску после первого абзаца). Таким образом, если абстрактный класс принимает свои зависимости через конструктор - вам необходимо принимать их же и передавать выше по иерархии наследования.

Т.е. если абстрактный класс выглядит как:

abstract class AbstractExample 
{
  public function __construct(Foo $foo, Bar $bar) 
  {
  }
}

а вам необходима ещё дополнительная зависимость Baz $baz, то ваш конструктор должен выглядеть примерно так:

class MyExample extends AbstractExample 
{
  public function __construct(Foo $foo, Bar $bar, Baz $baz) 
  {
    parent::__construct($foo, $bar);
    // ... и далее ваша логика ...
  }
}

Использую по возможности всё что есть в Sass и хотелось бы видеть в нём больше. Активно использую и переменные и миксины и функции и placeholder'ы и list'ы и map'ы и т.п. Многие практические задачи намного легче решаются через препроцессор, те же CSS variables ни разу не замена.

Конечно для того чтобы код не превратился в кровавое месиво - необходимо соблюдать правила, но это справедливо и для любого другого языка программирования. Да и без использования препроцессоров я видел огромное количество write only css который невозможно нормально поддерживать.

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

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

short_open_tag=on
в php.ini

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

Ваш текущий код работает по причине того что вы используете неявное создание нового объекта на каждый вызов через указание new Date() в качестве значения по-умолчанию. Это значение по-умолчанию вас и сбивает с толку т.к. оно выглядит как своеобразный генератор значений, хотя по факту им не является.

Кроме того await date тоже по факту работает не совсем так как вы (скорее всего) ожидаете. Из MDN: "If the value of the expression following the await operator is not a Promise, it's converted to a resolved Promise." Таким образом const currDate = await date в вашем случае эквивалентно const currDate = date.

Далее, следите за руками:

Сначала вы передаёте в setInterval функцию без дополнительных аргументов. Она работает по причинам, описанным выше.

Затем вы передаёте в setInterval() значение вызова setSearchTime() третьим аргументом (т.е. аргументом для интервальной функции). При этом, как вы сами пишете - функция setSearchTime() у вас возвращает Promise что по определению - обещание вернуть одно значение.

Таким образом когда вы передаёте этот третий аргумент - ваша функция начинает получает значение аргумента date (т.е. перестаёт отрабатывать генерация значения по-умолчанию). При первом вызове ваш Promise, переданный в качестве аргумента в интервальную функцию, переходит в состояние fulfilled и отдаёт значение, но дальше этого уже не будет происходить т.к. Promise уже в состоянии fulfilled, так что вы будете всегда получать одно и то же значение. Однако это будет происходить не потому что setInterval не работает, а потому что вы и передаёте одно значение.

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

Также пара замечаний которые не относятся непосредственно к вашему вопросу, но являются важными:

1. Ваша функция отображает время с точностью до минуты, но вызывается каждые 100 миллисекунд. Таким образом она 600 раз генерирует одно и то же значение что, очевидно, неразумно
   
2. Сама функция преобразования времени у вас не показана, но важно чтобы эта функция не опиралась на setInterval в качестве источника информации о количестве прошедшего времени. Вместо этого вы должны всегда отталкиваться от new Date() и модифицировать этот объект. В качестве примера почему так попробуйте себе представить что компьютер с браузером в котором запущен ваш скрипт, был отправлен в гибернацию на какое-то время, а потом вернулся назад
   

Можно воспользоваться тем фактом что в JavaScript в reduce()передаётся текущий индекс и сам массив, это позволяет упростить backreference. В итоге у меня получилось нечто подобное:

/**
 * @param {Array} list
 * @return {string}
 */
const range = list => list
    .sort((a,b) => a - b)
    .reduce((r, v, i, a) => {
        if (i > 0 &&  v - a[i - 1] === 1) {
            let l = r.pop();
            l.push(v);
            r.push(l);
        } else {
            r.push([v]);
        }
        return r;
    }, [])
    .map(v => v.length > 1 ? `${v.shift()}-${v.pop()}` : v)
    .join(', ');

Кусок с pop/push можно ускорить за счёт усложнения обращения к массивам, но так код получается выразительнее.

Отдельное спасибо Дмитрий за .sort((a,b) => a - b) - не знал

PHP поддерживает сравнение объектов DateTimeInterface напрямую, в данном случае стоит пользоваться именно этим:

$format = 'd.m.Y H:i';
$tz = new DateTimeZone('UTC');

$d1 = DateTimeImmutable::createFromFormat($format, '01.01.2019 15:24', $tz);
$d2 = DateTimeImmutable::createFromFormat($format, '02.01.2019 13:56', $tz);

$newer = $d1 >= $d2 ? $d1 : $d2;
echo $newer->format(DATE_ATOM);

Пока ещё возможно, через копирование файла addon'а в профиль и указание используемого профиля, но в ближайшем будущем такая возможность пропадёт, смотрите новость про Firefox 73, она как раз об этом.

В Symfony 4.4 будет добавлена возможность безопасного хранения ключей, подробнее в анонсе.

Поддержка Safari для Windows закончилась на версии 5.1.10 в 2013-м году.

Так что остаются только маки, виртуалки и сервисы типа BrowserStack.