Я знаю разработчиков, которые думают, что триггеры должны всегда использоваться, где это - самый прямой способ достигнуть функциональности, они хотят, и разработчики, которые никогда не будут. Это почти похоже на догму между этими двумя лагерями.
Однако я лично полностью согласен с MarkR - можно (почти) всегда писать код, функционально эквивалентный триггеру, который будет более ясным и поэтому легче поддержать.
Я думаю, что вы можете преобразовать searchString в DateTime и передать его как параметр динамической где сам метод.
itmes = items.Where( string.Format( "{0} > @0", searchField ),
DateTime.Parse( searchString ) );
Что, если вся лямбда создается динамически (мы пойдем с равными, а не больше), и тип не известен? В этом случае вы не можете использовать datetime.parse в параметрах где. Если вы попытаетесь пройти в объекте DateTime, Dynamic Linq интерпретирует его как тип INT32. Не могли бы вы сделать это, преобразовав галочки или миллисекунды данных DateTime и сравниваете это?