Да, это так. На самых ликвидных инструментах (фьючерсы RI, SI, ...) бар в 10:00 есть всегда, в малоликвидных - его как правило нет.

В защиту обращения по индексам замечу, что точное попадание в нужную границу не обязательно важнО. А в контексте использования сжатия - так и вообще не вАжно. Например, если сжать массив значений в более крупный таймфрейм и затем его разжать, то промежуточные бары будут одинаковы и, что source.HighPrices[bar - 810], что source.HighPrices[bar - 820] - все равно, эти значения будут одинаковы. Это позволяет не городить алгоритмически сложный огород поиска нужных границ.

Попытка хорошая, но, алгоритм далеко не оптимален и даже содержит ошибку.
Нет проверки на выход за границу массива. На первой же итерации будет выход за левую границу массива. Т.е. i-j окажется меньше 0.
Также, будет ложное выполнение тела цикла в случае, когда между барами будет ровно месяц. Условие:
sec.Bars[i-j].Date.Day==sec.Bars[i].Date.Day
лучше написать так:
sec.Bars[i-j].Date.Date==sec.Bars[i].Date.Date
т.е. сравнивать полную дату, а не день.
А не оптимальность в том, что есть ведь еще и основной цикл (внешний) по барам, и в каждой итерации этого цикла будут повторяться два приведенных while. Зачем? Это не оптимальная трата процессорного времени. Все можно сделать в основном цикле (см. мой пример) без поиска "назад" (тем более двойного).

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