Ну точное время разве что путем иттераций - восстанавливать эот лог (предварително восстанавливая полный [, диференциальный и более ранние логи - если есть] ) и использовать в with опцию Stopat, указывая время на котором надо остановиться и recovery. После чего смотреть есть ли в восстановленной базе нужная таблица или нет. Если уже нет, то повторить то же самое уменьшив время, если еще есть - увеличить и так до тех пор пока точность определения не станет достаточной :-)

Я тут вот еще что подумал:
можно несколько снизить время, если один раз восстановиь все что необходимо до нужного лога, а потом восстанавливать лог после которого таблицы уже нет в режиме StandBy, указывая Stopat в первый раз минимальным. После его восстановления можно проверить существование таблицы (т.к. бд доступна для чтения). Если таблица все еще есть, повторить восстановление только последнего лога увеличив значение StopAt. И т.д. до тех пор пока нужной таблицы в БД не окажется. Можно сделать все на автомате, т.е. если таблица существует, то прибавить Stopat и повторить восстановление последнего лога.
Преимущество такого метода - то что не надо каждый раз восстанавливать все предшествующие бэкапы.
Недостаток - то что при восстановлении всех пред. бэкапов можно скажем применить метод половинного деления - делить временной интервал последнего лога каждый раз пополам, и тогда, за N иттераций он уменьшится в 2**N раз, а при восстановлении всегда последнего лога за N иттераций временной интервал уменьшится только на N*M (где M - интервал приращения)...
Таким образом предпочтительност того или иного способа завиит от объема данных в предыдущих бэкапах и в последнем бэкапе и от длины интервала последнего бэкапа лога...